Alternative to True Image (nervous nellie)

I agree with a serial number, but nothing more than that.
I prefer to install all my softwares OFF-LINE in order to have at least one image backup file that is 100% clean.
Even winXPproSP2 forces me to use an internet connection for its activation and an activation by phonecall is too expensive for me. I tried the OFF-LINE activation method, but it didn't work.
And what everybody does, doesn't mean it is right.

FirstDefense-ISR is a software without all that crap, you don't even need a serial-number to install FD-ISR.

 

If it satisfies your particular requirements, then that's perfect!

 

I can't add anything to the discussion of ATI versus IFD. I've used both with happy results.

Those who, like myself, don't like making an image from within Windows because we're afraid that Windows files will change before the image is made might be interested in Terabyte's new Image for Linux. It is not especially meant for those who use Linux as an OS. You use a boot disk to load it, as with IFD or the ATI rescue disk. What it offers is that it's as fast for many users as making an image from within Windows. What is not so good is that some users say it doesn't see their USB external drives or DVD players.

Best of all, if you own IFD you can download Image for Linus without further charge. I did and I'm a convert.

Good luck, Dan

 

One of the primary purposes of Microsoft's VSS framework is to enable live backup within windows while simultaneously ensuring that all file system metadata is in a clean state and flushed to disk prior to the snapshot creation. VSS will also ensure that VSS-compliant "writers" (applications which generate data on the volume) are properly quiesced prior to the creation of the volume snapshot. For most situations, this means that a hot VSS backup is plenty good, and you'll be well served by any VSS-aware backup application. If you actively use non-VSS-aware writers, then it can be a good thing to take a "cold" image of your volume(s) from an alternate environment. Hot backups of systems on which non-VSS-aware writers are active capture those writers' data in essentially a "crash consistent" state, meaning that for those application's data the backup will have captured their data at a single moment in time, before the application terminated, which is similar to the state of the data if you hard-power-off the machine.

 

I have successfully used HDS Clone version 2 boot CD.
Imaged my C partition NTFS that is protected by RollbackRx and was having 3 snapshots plus current system. I made an image in partition D that was specialy formatted in FAT 32 for this purpose. After that I uninstalled RolbackRx with my base line snapshot to persist.
Restored image, and got RollBackRx console with all images and current snapshot at the time of imaging. I am able to boot in the snapshots, they are not corupt at all, no error mesages during all this procedure, every thing is fine. I rebooted in all snapshots one by one, did this on a test laptop with XP home.

C drive data size with RollbackRx 3.6 GB
Image time 7 min
image verification time 3 min
Image restore time 5 min
Image size about 2.3 GB(althoug image size is 2.3 GB but I noticed u need a space almost equal to or a little less than C drive data size, 3.6 GB in my case, otherwise imging will not start. It is minor bug in any case.
HDS clone is very easy to use infact and is free.

 

If you do image based backup, VSS is irrelevant.
An image based backup is taking a snapshot at a point in time.

If you want a fixed state for the files, then you have to create the backup outside of Windows.

 

Howard, I'm puzzled by your statement, that "if you do image based backup, VSS is irrelevant." I'd like to understand why you say this? Are you referring to the needs of home users specifically, or are you making a general statement?

Having personally worked directly with the VSS API in the creation of two mainstream image-based backup products (VSS requestors), my opinion is that VSS is incredibly useful for image-based backups. Without VSS, the snapshots are taken when file system metadata and application data is not in a clean state and flushed to disk. With VSS, all of your VSS-compliant writers (such as Exchange, Oracle, Sql Server, IIS, etc) as well as the file system(s) have flushed data to disk at which point these writers pause for a fraction of a second while the VSS software provider (the VSS-compliant snapshot driver) establishes the snapshot after which the writers are released. While no image can beat the quality of a "cold image", taken from an alternate boot environment, VSS-based images are much higher quality than "crash consistent/state" images. For the home user it's probably not much of an issue. Home users have no problem taking their machine down to boot into an alternate environment in order to capture a nice cold image. Enterprise users, or power users who schedule frequent backups, generally can't afford this downtime and so while VSS may not be as important to the home user, it plays an important role in the enterprise, as it allows you to obtain "a fixed state for the files" without leaving Windows.

 

I looked thru most of this thread, but I'm not sure exactly how to make an incremental backup using IFW...

 

IFW doesn't make incremental backups, only backup images.

 

Quoting from Major Updates Coming...:

"TeraByte plans to release major updates of its drive imaging products (IFD/IFW/IFL) by the fourth quarter of 2006. The updated product(s) will include several new enhancements and unique features. The restoring of images created by the current 1.x versions will also be supported...

...Two of the new product features will be password protection and differential backups. Full details of the new and improved features will not be released until the product nears completion."

Nick

 

Thanks Nick! Something to look forward to.

I hope they also will offer a "Files and Folders" backup in the future.

 

You better read the Terabyte website to get a total picture of the possibilities of BING/IFW/IFD.
Users usually don't tell you everything about a software and don't mention everything in posts either, because they forgot it or they don't use it or they don't like it, etc. ...

 

It was my understanding that image based backups locked the drive currently being backed up.

 

If someone wrote that BING/IFW/IFD do incremental backups, they were mistaken, PERIOD. There's nothing to forget because it was never there. IFW/IFD, up until now, has been a stictly point in time imaging program.

 

That's not what I meant, but I'm not going to discuss this. Not important enough.

 

Does Terabyte have a web support forum?

 

Ah, I see that they have newsgroups, not web forum.

 

Oh, I see. This is true for older generation backup products, which do not incorporate snapshot technology. However, latest-generation image-based backup applications usually employ snapshot technology, and the sole purpose of snapshot technology is to enable the backup application to capture the state of the volume at a point-in-time without the need to lock the volume or stop any of the applications that are using files on the volume.

Maybe it would be useful to the forum to describe exactly what "snapshot technology" is. The goal of snapshot technology is to instantaneously capture all of the data on a volume at a given point in time without interrupting I/O to that volume (without locking anything, stopping applications, etc). This is invariably implemented using an "upper volume class filter device driver" which intercepts I/O underneath the file system, but above the volume devices (see the storage stack diagram below). When the snapshot device driver is instructed by the backup application to establish a snapshot of a given volume, it immediately starts tracking changes that occur to that volume. Each time a write occurs on the volume the snapshot driver first copies off the old data that was already at the location into some scratch pad area and then allows the new write operation to continue on down to the device. Thanks to this copy-on-write mechanism, the snapshot driver is able to preserve all of the information necessary to expose to a backup application the data that was on a volume at a given point in time. Snapshot drivers usually expose the snapshot point-in-time by creating a virtual device similar to a volume device. The backup application will read the sectors on this virtual device in the same way that it would have read them from the real volume. The backup application *may* lock access to this virtual snapshot device, but keep in mind that this virtual device is generally only used by the backup application (it's not visible to normal applications). Locking the virtual snapshot device has no effect on the actual volume device that is being backed up - the real device is never locked and remains accessible to applications. Because snapshot device drivers sit within the storage stack itself, they have absolute control of the flow of I/O to the disk. When a snapshot driver is instructed to establish a snapshot, it takes only a few microseconds, if not less time, for it to halt I/O to the device and establish the necessary in-memory structures necessary to maintain mappings of which sectors have been changed (causing copy-on-write operations) since the establishment of the snapshot, and then to allow I/O to recommence. It's important to understand that there is a difference between the act of "taking a snapshot" and the act of "imaging the data on a snapshot". Taking a snapshot requires only a few microseconds, if not less time. Imaging the snapshot is the process of backing up all of the data that are exposed by the snapshot device driver for a particular point-in-time (usually exposed as I mentioned by a virtual volume device), which is all of the data on the drive at a given point in time, and this can be a lenghty process. When a plain-vanilla snapshot device driver creates a snapshot of a volume, it is instantaneously capturing the volume's state at a given time, and the state of the volume's data is very similar to the state of its data if you kill the power to the computer. This is called a "crash consistent" state. The reason for this is that, at any given time, many files are open and in use and also the file system itself can have structures which are write-cached and have not yet been flushed. Creating a plain-vanilla snapshot captures the data in this in-use state, so it's not a very clean snapshot (it's "crash consistent"). VSS was introduced with Windows XP, and one of its primary purposes is to facilitate the establishment of snapshots when the data is in a clean state. To do this, backup applications and snapshot drivers must be written to interact with VSS. VSS controls the snapshotting process. The backup application will ask VSS to take a snapshot, using a specified snapshot "provider" (snapshot device driver). VSS will then tell all VSS-aware "writers" (applications which generate data such as Exchange, Oracle, SQL, IIS, and many system services such as the registry, etc) to quiesce (meaning that these applications flush their files to disk in a state that is clean and then pause for a small moment until they are told to resume activity) and then VSS will send a special flush-and-hold message (IOCTL) to the file sytem on the volume on which the snapshot is being established and when the file system receives this flush-and-hold message it will flush all of its metadata to disk and it will then send this flush-and-hold message further down the stack and the file system will not send any more I/O down the stack until the flush-and-hold IOCTL is completed by the snapshot driver which resides below it (which establishes an I/O barrier at the file system level). When the snapshot driver receives the flush-and-hold IOCTL, it knows that all VSS-aware applications as well as the file system itself have flushed their data in a clean state, so it establishes the snapshot and then completes the flush-and-hold IOCTL, which completion event is then received by the file system driver above it at which point the file system driver releases I/O and passes the completed flush-and-hold IOCTL back to the VSS service, which then releases all of the VSS-aware applications. Through this mechanism, VSS-compliant backup software, which use VSS-compliant providers, can create backups of extremely high-load Exchange, Oracle, IIS, SQL, etc. servers on a regular basis without the need to stop any services or applications, without shutting down the machine, while also ensuring that the backups contain good clean data (databases will not need to be fixed/repaired if they are restored, because VSS ensures that they are captured in a good state).

On platforms older than XP, where VSS is not present, other techniques are used to obtain images which are better than crash consistent state images. For instance, some snapshot drivers implements their own I/O barrier at the file system level (using a file system filter driver), if necessary, and on platforms that lack VSS (Windows NT and 2000) the driver is capable of performing the file system flush-and-hold operation which is natively supported on XP+. This enables it to perform snapshots at a time when the file system's metadata has been flushed to disk. Coupled with this is a more manual quiescense process which is facilitated by the backup application itself, which enables users to specify scripts which they wish to be called before and after the establishment of the snapshot, which scripts can be used to stop/start services, etc (or in other words, the scripts are a way of quiescing important applications). While this is more tedious, it gives users of older platforms, that lack VSS, some of the advantages of VSS.

Windows Storage Stack

I/O within the Windows kernel flows from one driver to the next until it is finally passed directly to the hardware device. Each type of device typically has several layers of drivers that manage I/O as it flows to the device. For storage, I/O generally is initiated in user mode (from applications) and is passed to the kernel's I/O manager where it then forwarded to the appropriate file system driver, then to the volume class driver, then to the disk driver, and finally to the storage controller port driver. Filters can be added at any level in this stack.


----------------------
|Win32 Application(s)|
----------------------
|
-----------------
|Win32 Subsystem|
-----------------
|
---------------
|Native NT API|
---------------
|
-------------
|I/O Manager|
-------------
|
--------------------
|File System Filter|
|Driver(s) such as |
|AntiVirus Drivers |
--------------------
|
--------------------
|File System Driver|
|such as NTFS.SYS |
--------------------
|
--------------------
|Volume Filter |
|Driver(s) such as |
|Snapshot Driver |
--------------------
|
-----------------
| Volume Driver |
-----------------
|
-------------------
| Filter Driver(s)|
-------------------
|
---------------
| Disk Driver |
---------------
|
-------------------
| Filter Driver(s)|
-------------------
|
--------------------
| Port and Miniport|
--------------------
|
-------------------
| Actual hardware |
| device |
-------------------

 

Yes, but even snapshots do not get the job done.

Any (image) backup is a snapshot at a point in time.
So called snapshot technology just redefines the point in time.
But changes are almost constanly occurring to drives.
And changes on one volume are related to changes on other volumes, e.g., due to registry references to other volumes.

The only way to get a "clean" backup is from outside of windoze, anything else is a hybrid and is usually good ;nuff.

 

I guess that depends on exactly what kind of job you want to accomplish. If your goal is to capture the best state possible, regardless of whether applications must be stopped or even the host shutdown and rebooted to an alternate environment, then certainly cold images are optimal. If you can't stop operations or applications, then snapshots are vital, and surely *do get the job done*. There is no solution (snapshot-based image vs. cold image from alternate environment) that is the absolute best for all situations, so it's important to identify your needs in order to select the best solution.

True, and this is why snapshot is necessary. If you simply performed DASD reads straight off of the volume device, while it was in use, in order to back up its data to an image file, then of course the image file would contain garbage. Snapshot enables you to instantaneously capture the data on volume while allowing continued, uninterrupted, use of the volume.

I'm glad you brought that up! In fact, this specific scenario (where dependent data is spread across multiple volumes) is specifically addressed by the VSS framework, and mechanisms are in place within VSS to ensure that interdependent multi-volume data can all be flushed simultaneously and all captured in a clean state, without interrupting application services.

Yes, there's no doubt that the best quality backup image is taken from an alternate boot environment. The advantage is that you know for sure that all data is in a clean/closed state. However, with the right software (snapshot properly integrated with VSS) you can obtain backups of equal quality *for the data you care about* without shutting down your machine or stopping applications. I can backup an Exchange server under massive load every fifteen minutes (incrementals) and restore any of these backups without any errors in the Exchange database. Many companies live and die by the data in their Exchange database. For them, this type of functionality is absolutely critical. While for some users, cold imaging (from an alternate boot environment) is the ideal solution, for others it's the worst option.

 

Just out of curiousity, do you know of any techniques, which are not cost-prohibitive (such as hardware dongles), that effectively prevent piracy but do not require the user to enter any unique information at install/registration time? If so, then I'd be very interested to understand how they work. I have my doubts, but if it's possible that'd be great!

 

Of course, Peter, I read that and that's why I said "up until now". I don't know why I bothered to quote Erik, my bad, as the information was intended for djkym.

Well, I didn't mean what you thought I meant and I'm not going to discuss it either.

 

thanks for all the replies--

for all those that uses bing/ifw, etc. who need incremental backups (to reduce storage overhead), what are you guys using in the meantime until TB comes out with it?

i'm mainly needing a system to backup a database (altho i haven't decied what type of databse to use)

thanks,
dk