questions about verification of backup

I have the box checked that says to verify the backup after running it. What that appears to have done is put one step in the task to do the backup, and another step to verify the backup. So given that, I have those same basic steps in place in one task for a full backup, and in another task for a differential backup.

What I'm seeing is when I do the differential backup, the verification step appears to go back and verify the entire backup, not just the differential part that has changed since the last run, so it takes quite a bit of time to perform the verification. Is there any way to change it so it verifies only the new changes rather than the whole backup so it will execute faster? (I typically run manually rather than schedule automatic backups for a couple of reasons that aren't worth getting into, so I'd rather it finish as quickly as possible)

Also, I've seen something kind of strange while the progress bar is moving along during verification, but I don't watch it every time so I'm not sure if this is consistent or not, but I think it is. It shows the progress and time remaining, and then suddenly finishes when it hits 50% (in the lower right corner) and had previously displayed something like "9 minutes remaining" in the progress window a few seconds earlier. The one time I was watching it the top green bar had reached the far right end, and the lower green bar was about halfway done when it finished. Is this a bug or what? Is it doing a full verification and reporting the time remaining incorrectly, or just skipping the last half of the verification step and finishing early?

 

Because the Diff is useless without the Full, Acronis has chosen to verify the whole wad. Right or wrong? depends on your purposes. If you make several diffs based on a full, you'll need all of them to be able to validate even though you only need the last diff and the full to do a restore. Go figure.

 

Yeah I figured it was something like that, so you're saying I have no choice in my verification choice, it either does it all or nothing, that's what I thought.

Seems logical to me if the tool can determine what the differential database is, and write it to a separate file like it does, then it should be equally able to verify just that separate file got written correctly. We already know the initial full backup file got written correctly if it was verified in the process. So I could either be truly anal and re-check it every time just to make sure it didn't somehow get corrupted in the meantime, or more practical and just verify the new data got written properly. Seems like a simple switch could implement that choice very easily.

I have a copy of Dantz Retrospect Express 6.0 that I got for free a few years ago with a Maxtor USB drive and it seems to be able to do the incremental verification with just the differences.

 

It's always your choice, but verification is largely a waste of time. A verfiied file may not restore, and the only true test is to restore.

Files may verify under Windows, and that really doen't matter because the restore is always under Linux. If you must verify, use the recovery disk and use the verify available there. At least you'll know the recovery disk can find and open the file.

Verify does not compare the contents of the disk to the contents of the backup.

Have fun!

 

so what does verify do?

So what does it do?

Regarding why I feel the need to verify even though you claim its not worth it:

I had an interesting experience with Norton Save and Restore a few months ago. I did a backup of some photos, etc. with a basic file save backup (i.e. not a disk image) onto an external HD. A few weeks later I noticed for some reason about 10GB of the external drive was 'missing' (if I added up the file sizes on the disk and compared that number to the amount used if I looked at the root drive letter in Explorer). Finally ended up reformatting the drive because I couldn't figure out where the missing 10GB was.

After reformatting, S&R wouldn't backup those same files any more because somewhere in its database it had a record of all those files being backed up, and the files hadn't changed since the last backup, so it considered the job done. So I had a backup tool that wrote files into some 'ether' and didn't ever check to make sure they arrived at their destination. I had lost all the backup files, and S&R was completely unaware of it!! Even worse, it wouldn't let me manually back them up because it claimed all was well and it didn't need to be done.

So, I never investigated how to delete the S&R record to get it to re-backup the files, I just uninstalled that piece of crap and bought ATI. Now after spending a little time on this forum it appears ATI has many bugs of its own, so I'd rather do a little verification just to boost my confidence a little that it has really backed up what it says it has.

 

Assuming that you are relatively new to Acronis I can understand that you may want to verify. It seems to me that Acronis either works or it doesn't. If you have no conflicts and it works then you will find that it works each and every time and may then agree that verifying is a waste of time. Having made over a thousand full images and restored even more times I have yet to have a failure.
If disaster struck and an image failed I would simply go back to the previous image. I must admit I'm assuming here that you are going to actively restore on a regular basis ? system image to a system partition or drive and data image to any old drive ? to use verification and never to restore ( just waiting for a disater to strike ) is far more dangerous than actually restoring and forgetting all about verification. To keep life simple I also ignore incremental or differential backups.

 

OK, educate me a little more here

I can't figure out why I should routinely restore my system disk if I don't encounter some sort of disaster, but it sounds like that is what you are suggesting. Given the number of posts on this forum of the nature "restored C: disk but PC won't boot" or "corrupted image" the last thing I want to do is try a system restoration just for the hell of it. If I wait until disaster strikes then the worst I can do is break even (failed restore). If I do it for the fun of it only to hose a perfectly good system disk, then what recourse do I have? Sure, if it works the first time then I know I can trust my backup, and always go back to that version if future problems occur, but if the first try doesn't work then I'm basically screwed, right? You said yourself it either works or it doesn't, so I'm not really interested in finding out what to do next if it doesn't. Am I not understanding something?

 

Re: OK, educate me a little more here

There are a number of reasons for routine restore (1) You want to try a new program. You make an image. install the new program - play with it for a day and then restore. (2) it may be weeks after you have installed a program that you notice a problem. you may then be glad to go back to a full image from2 months ago (3) In the old days many would do a complete rebuild - just to get a free clean system. Today I can install a clean version of Xp and build from there more quickly. The most important is that it a restore is the only way to guarantee that a restore will work on your hardware.

I wouldn't take these posts too seriously. Every program has people with problems and these are the ones that tend to write in. There are many, many more out there who have never heard of wilders and find that Acronis just works.

I said it works or it doesn't meaning that once you have found out(proved) that it works you are very very unlikely to experience problems later on. I think you ought to be interested in finding out what to do next. I tried Acronis and have had no difficulty. I tried other similar programs and they did not work. Making an image is only half of the job. If you find that Acronis can restore then fine. If it doesn't then you better find out why and or get another program

 

Some people do a test restore to a second hard drive. To prove their image.
I do much like Long View does I keep many images and use them for restoring after trying out a new program for a week or so and I also restore to get rid some particularly bad virus or spamware, which as the years go by I have learned how to avoid them for the most part.
After updating to XP on my computer I made an image and would restore back and forth from one operating system to the other until I had XP patched and all the programs I needeed installed. I keep the very first image of XP and an image of the patched version with the "necessary programs". If I ever want to start with bare bones XP I can simply do a recovery. I only keep about 14 gigs of "used" space on my "C" drive and this takes about 8 minutes to restore or to recover. I do regular full images. ( once a week). When I first started I never even noticed the "validate" and just out of curiosity I tried it just a while ago and it worked fine from windows and from the rescues disk. ( But I don't bother with it).
I have two internal hard drives and two external hard drives with many images as well as my pictures, videos and music which I copy and paste, then delete from my "c" drive. I only have one partition on my "C" drive and three on my other external drive ( One for images).
Good luck in your endeavors

 

For your question regarding what does a verify do, I see it has not yet been answered. In simple terms the verify ignores your disk content entirely, and works only with the backp file to make a series of check sums and compare them to what was written into the file when it was created.

It's not possible to compare to disk contents, since the very act of making an image alters the disk contests.

In a nutshell, a file may verify and yet refuse to restore, or fail verification and still install. I have better uses for the time.

Have a fine day, and enjoy your Acronis adventure.

 

Image verifications give a certain degree of confidence. I prefer certainty. My way of ensuring this is to restore images to a rotation of three main hard drives.

My images are proved as they have actually done full restores and are available in a secure zone on a secondary internal hard drive should it ever be necessary to go back in time. In about four years of working with imaging I have never had to go back more than two days so these images are a safety-net I will probably never need.

My current backups are on two of the three main hard drives. These wait in their caddy drawers outside the computer for their turn to be refreshed by a restore or brought into use when disaster strikes.

In more than 18 months of working like this I have had a few very rare restore failures. Because I never restore to overwrite a current drive they have been of no consequence. I believe the fails have been due to poor hardware connections or cables. I have now re-made or replaced them.

Xpilot

 

Validation only rechecks the check sums in the file that are inserted inthe file when it is created. It's not a comparison to the original data.

There are set ups where a tib won't verify in Win but will bith the BootCD or vice versa. So a perfectly good tib might not validate but still restore. Also, a tib mightr validate in Win but not with the BootCD and not be restorable. So validation is only a soft indicator of a good tib. These issues result from ATI not being able to properly address drives in some set ups -- and sometimes it can address drives in Win but not inthe linux environment of the Boot CD.

However, if you do a test restore, then you can be confident that backups can be restored with the BootCD on your hardware, in which case, with those hardware issues out of the way, validation is a stronger indicator that tibs made on your machine are good for restoring.

Personally, I don't do validations -- I do test backups and restores after installing a new version or upgrade of ATI, which is essentially what xpilot has recommended too. I don't test every backup I make -- if I had to go to that much trouble for confidence, I think I'd shoot myself ;-).

There are setups on which ATI 11 can recognize drives in win and can recognize them when you select a backup to restore but can't see them all when you try to select a target for the restore. In that situation, only an attept to restore would reveal the critical problem. If data integrity is important, then a test restore is important -- at least attempt up through the steps of picking a target for a restore.

How much confidence you need is a personal matter but don't mistake validation as proof that you can restore.

 

The real benefit of verify in my experience is to provide confidence in a system which has not previously been proven. This includes the first time you install and use TI on a particular PC, and whenever changes to the BIOS or hardware are made.

Image integrity problems can arise if you have faulty memory, faulty cables, a faulty power supply or are overclocking your system. The same system however may behave normally when running other applications even though it is carrying these faults/configurations.

Once it is clear that images verify OK on a given fixed platform, the use of the verification phase is questionable IMHO, particularly if DR is being done properly and periodic restorations are being successfully made.

Verify for me is simply a confidence check for the platform. Once done and you can restore succesfully, forget it unless you change your system.

F.

 

I realize this is a personal view but if my computer has a file integrity problem with only one program, then it's the program and not the machine that is odd man out and that program goes out the window -- there's too much software competition to screw around trying to finesse my hardware for one program that can't play on the same field as everyone else.

I guess there's no room for canaries in my coal mine -- if you can't work in the mine, get out of the mine ;-)

 

My perception (and indeed my own experience in three cases) has been that such faults can cause TI to run into problems simply because it stresses the system in ways that no other application does. In two cases of failed verifications, Memtest showed faulty RAM. Once that was fixed TI worked and verified fine.

Is the fact that TI relied on that RAM working down to the bit (whereas you might not notice or care in say something like a digital photograph with a corrupt bit) a hardware fault or a (TI) software fault ?

It seems pretty obvious to me

F.

 

Yeah, I've thought about doing that, I have a second internal drive connected so I could give it a try. Could you please answer a few basic questions for me regarding the process so I don't do something stupid along the way? My goal is to try to restore the system onto the second drive after swapping it into the old C drive location and use the bootable disk that comes with Acronis to do the restore. I think that most closely resembles what I'd have to do in the event of a catastrophic failure (as opposed to making a duplicate copy on the other drive with the current OS intact and then swap the drives after doing the restoration without using the boot disk)

My second drive currently has only one partition (G) for the entire drive (200GB). So the first thing I'll have to do is add another partition similar in size to my current C: partition, which is about 34GB, so that shouldn't be any problem. I have Partition Magic to help with that.

My first question is this: If I add a new partition (F) *before* the existing G partition, what actually happens to the existing data in the G partition? I think the current G partition starts at the 1st sector on the physical drive. Will the new F partition actually allocate physical sector space after the current G partition, then just logically map it with a new MBR table entry to point to the first sector location? Or will the re-partitioning actually move the existing G data on the drive, and physically place the F partition at the 1st sector?

I hope its the latter, because I think when I restore the system image onto that drive it has to reside at the first physical sector because that's where Acronis will place the MBR from my original image, right? And as long as I made the new partition bigger than the original C partition, that space will be available to restore the system image without writing over any of the old G partition data that I don't want to disturb.

Next question: Does the drive that contains the OS/system code always have to be hooked up to the first position cable so the boot process can find the MBR? I think it assumes sector 0 on the first disk it finds will have the MBR, but I'm not sure. So I think that means I have to swap the cables on the two drives when I do the boot/restore.

Next question: The old MBR that will get restored knew about the F and G partitions when that drive was connected to the other cable, but now that the cables have been swapped between the drives what impact will that have on the MBR data? Will the PC be able to recognize the physical disk and determine that its been swapped, and adjust the MBR info accordingly? Will the old F and G partitions now be called C and D? And what about the partitions on the old C drive, will they now start at E? I assume the PC must be able to figure this out upon boot, otherwise the old MBR would be worthless in the restore process.

So given all this uncertainty, I think all I have to do is this:

1) add F partition to 200GB disk
2) swap the disks
3) reboot with the Acronis boot disk
4) follow directions to restore the system image from my old C drive
5) reboot again to see if it worked

Given what I've described above regarding my system, will I have to do anything else?

thanks in advance!!