restoring only C drive on 64-bit Win 7

[userX]

Once again I have good reason to appreciate the value of IFL because it worked flawlessly in my most recent "for real" recovery procedure. Honestly, I must admit that I was a "wee bit" concerned because I had not had to test it yet in an identical, live scenario such as I faced this time, recovering only one partition of a disk with multiple partitions and the one being the system partition of a 64-bit Win 7 OS. Nevertheless, it functioned perfectly the first time through without so much as a hiccup.

Even so, I wanted to confirm a procedure to make sure that my approach was sound. Originally, I had made the backup image of the whole disk, I.e., of all three partitions, including the Win 7 boot partition, the system partition with C drive, and an unmapped partition of the disk containing the OEM recovery data, which was made to restore the OS to its initial pristine state. Later, the second backup was a "changes only" differential backup having only the whole disk image data to base it from. The next several backups were incremental "changes only" backups because in each case I pointed to its preceding "changes only" backup image instead of pointing to the original whole-disk backup image, as I had to do for the second procedure. I think it is important to note also that my original whole-disk backup image was made using the IFL CD environment but all the subsequent "changes-only" incremental and differential backup images were made within the live Windows OS environment while I was also working in this environment. I was backing up these images to an external disk device attached to a USB 3 port on the laptop. I put this disk's original whole-disk backup image and each of the changes-only data images into the same folder on the external disk, allowing them to have the name assigned to them by the program without modification because its scheme works well for me and includes the dates for me to keep them properly ordered as it is.

Now, during the recovery procedure, I needed to recover the C drive only, on which I keep the OS and the bulk of its routine data files, as I assumed nothing else from the other two drives had changed; and I wanted to restore it to the state it was in prior to the very last backup image. In other words, I wanted to recovery it to the state it was in right after I had made the "next to the last" image. I had to avoid using the last image. So, during the actual restore procedure, which I made from the IFL CD environment, instead of selecting the top-level disk for restoring, which would have automatically recovered all three partitions, I checked off merely the C drive for recovery.

I then browsed out to the attached external disk, drilled down to the folder where I had saved the sets of "all" of these images, and I pointed to the "next to the last" one of them as the backup image for recovery. I was not asked by the recovery procedure for any other information in regard to which of these other images should be used. Therefore, I am under the assumption that it "knows" to use it along with all the preceding images in this set, and only in this folder, all the way back to the original whole-disk backup, at which point it would stop looking. Is that not so?

Finally, it was not necessary for me to select any other of the many options relating to disk geometry, MBR, active state, etc. I left all these options unchecked, such as they were already by default, except that I chose simply to validate the backup and shut down afterwards. This is basically all there was to it. Was there something else I ought to have considered or done differently? It appears to have worked flawlessly.

[TeraByte Support]

yes, sounds right - to see how it works if you moved a file, move one to a
different directory as a test, then validate the last incremental and you'll
see it will end up asking where that file is.

"userX" wrote in message news:[email protected]...

Once again I have good reason to appreciate the value of IFL because it
worked flawlessly in my most recent "for real" recovery procedure. Honestly,
I must admit that I was a "wee bit" concerned because I had not had to test
it yet in an identical, live scenario such as I faced this time, recovering
only one partition of a disk with multiple partitions and the one being the
system partition of a 64-bit Win 7 OS. Nevertheless, it functioned perfectly
the first time through without so much as a hiccup.

Even so, I wanted to confirm a procedure to make sure that my approach was
sound. Originally, I had made the backup image of the whole disk, I.e., of
all three partitions, including the Win 7 boot partition, the system
partition with C drive, and an unmapped partition of the disk containing the
OEM recovery data, which was made to restore the OS to its initial pristine
state. Later, the second backup was a "changes only" differential backup
having only the whole disk image data to base it from. The next several
backups were incremental "changes only" backups because in each case I
pointed to its preceding "changes only" backup image instead of pointing to
the original whole-disk backup image, as I had to do for the second
procedure. I think it is important to note also that my original whole-disk
backup image was made using the IFL CD environment but all the subsequent
"changes-only" incremental and differential backup images were made within
the live Windows OS environment while I was also working in this
environment. I was backing up these images to an external disk device
attached to a USB 3 port on the laptop. I put this disk's original
whole-disk backup image and each of the changes-only data images into the
same folder on the external disk, allowing them to have the name assigned to
them by the program without modification because its scheme works well for
me and includes the dates for me to keep them properly ordered as it is.

Now, during the recovery procedure, I needed to recover the C drive only, on
which I keep the OS and the bulk of its routine data files, as I assumed
nothing else from the other two drives had changed; and I wanted to restore
it to the state it was in prior to the very last backup image. In other
words, I wanted to recovery it to the state it was in right after I had made
the "next to the last" image. I had to avoid using the last image. So,
during the actual restore procedure, which I made from the IFL CD
environment, instead of selecting the top-level disk for restoring, which
would have automatically recovered all three partitions, I checked off
merely the C drive for recovery.

I then browsed out to the attached external disk, drilled down to the folder
where I had saved the sets of "all" of these images, and I pointed to the
"next to the last" one of them as the backup image for recovery. I was not
asked by the recovery procedure for any other information in regard to which
of these other images should be used. Therefore, I am under the assumption
that it "knows" to use it along with all the preceding images in this set,
and only in this folder, all the way back to the original whole-disk backup,
at which point it would stop looking. Is that not so?

Finally, it was not necessary for me to select any other of the many options
relating to disk geometry, MBR, active state, etc. I left all these options
unchecked, such as they were already by default, except that I chose simply
to validate the backup and shut down afterwards. This is basically all there
was to it. Was there something else I ought to have considered or done
differently? It appears to have worked flawlessly.

[userX]

"yes, sounds right - to see how it works if you moved a file, move one to a
different directory as a test, then validate the last incremental and you'll
see it will end up asking where that file is."

I am just going to take you word for it. Thanks for the clarification.