Restore a complete backup set all at once in one operation?


Author
Message
twgonder
twgonder
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)
Group: Forum Members
Posts: 18, Visits: 45
I'm looking to see if there is a way to automatically restore a complete set of backups after a full(F) image backup and differentials dif(D) and incrementals(i) are run.
It can get a little overwhelming if a full is done once a month, then differentials each week afterward with several incrementals daily.
I see that the delete of a full from within Reflect will delete all the associated saves, but what about restores?

For example, in a month we might have : F,I,I,I,I,I,I,D,I,I,I,I,I,I,D,I,I,I,I,I,I,D,I,I,I
and depending on the retention settings, all the files might be present.
One might want to recover a complete system, but only the F and last D, and three I s are needed.
Can all those be restored in one master operation? Who wants to sort through all those files and then restore each one individually with possible errors from sleepy eyes?

Is there anything in Reflect to stop an error like restoring the F, the last D and missing the first I, but restoring the second I?
Suppose we don't want the last I for some reason. Maybe check boxes to control up to what point the restore will run?
I´m guessing that just restoring the last I on an empty target drive won't go get the F, D and other I s. (but I can't test it right now)

So far I haven't seen this feature. Have I missed something?
Edited 11 February 2020 3:29 AM by twgonder
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
It's surprising to me how many people assume that backups in a set have to be restored individually and sequentially.

The reason you're not seeing a specific feature for what you're asking about is because your guess in that last part of your post was wrong.  Reflect is already designed the way you'd hope.  You're overthinking the necessary restore steps.  Reflect's design is very simple: Select the backup corresponding to the state you wish to restore to, and Reflect will pull whatever data is necessary from the various other backups in the set to restore your target to its state at the time of the backup you selected, all in a single restore operation.  You don't have to restore the Full first, then each subsequent child backup -- in fact if you did that on the Free version, you'd be running tons of restore jobs with each one overwriting the work of the previous job, so it would take forever and most of that time would have been spent on redundant work.  With the paid version, you'd at least save some time thanks to RDR if you did that, but you'd still be wasting time compared to just choosing the backup you want to restore to in the first place.

So yes, immediately choosing to restore the last Incremental in a set onto an empty drive will indeed also restore all necessary data from the parent backups.  Restoring an Incremental does NOT mean that it only restores the data actually contained in that specific Incremental file, as you seem to be assuming.  That would be completely useless because all you'd end up with on your target would be a bunch of data fragments, so it wouldn't make sense to even allow that operation.  It would be totally unintuitive and unhelpful to end users -- which is precisely why Reflect is designed the way that it is, where users don't have to worry about what specific data is where in their set, and instead they just have to say, "Take me back to this point in time" and count on Reflect to do what needs to be done to achieve that.

Edited 11 February 2020 4:02 AM by jphughan
twgonder
twgonder
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)
Group: Forum Members
Posts: 18, Visits: 45
jphughan - 11 February 2020 3:32 AM
It's surprising to me how many people assume that backups in a set have to be restored individually and sequentially.

The reason you're not seeing a specific feature for what you're asking about is because your guess in that last part of your post was wrong.  Reflect is already designed the way you'd hope.  You're overthinking the necessary restore steps.  Reflect's design is very simple: Select the backup corresponding to the state you wish to restore to, and Reflect will pull whatever data is necessary from the various other backups in the set to restore your target to its state at the time of the backup you selected, all in a single restore operation.  You don't have to restore the Full first, then each subsequent child backup -- in fact if you did that on the Free version, you'd be running tons of restore jobs with each one overwriting the work of the previous job, so it would take forever and most of that time would have been spent on redundant work.  With the paid version, you'd at least save some time thanks to RDR if you did that, but you'd still be wasting time compared to just choosing the backup you want to restore to in the first place.

So yes, immediately choosing to restore the last Incremental in a set onto an empty drive will indeed also restore all necessary data from the parent backups.  Restoring an Incremental does NOT mean that it only restores the data actually contained in that specific Incremental file, as you seem to be assuming.  That would be completely useless because all you'd end up with on your target would be a bunch of data fragments, so it wouldn't make sense to even allow that operation.  It would be totally unintuitive and unhelpful to end users -- which is precisely why Reflect is designed the way that it is, where users don't have to worry about what specific data is where in their set, and instead they just have to say, "Take me back to this point in time" and count on Reflect to do what needs to be done to achieve that.

Cool, but that's how we used to have to do restores with media, like 1/2 tape and cartridges, so it's not that unusual to think that way. However, you said: "onto an empty drive" (which was my original post). I'm guessing that your saying that it will work on a drive full of newer data, get rid of the newer data (although we´ve had that doubtful discussion in another post) and get us completely back to the chosen incremental (or whatever). Thanks again for responding. I will test it and see some day when I'm feeling lucky (along with again putting a new file on the disk to see if it disappears).
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
Well with a tape strategy, you generally don't have all of the necessary backup data available simultaneously as you do with Reflect when all backups are sitting in the same folder of a hard drive or network share.  But at least when I was working with tapes, I remember that I could choose to restore an Incremental backup, and if the application needed the parent backups, it would prompt me to provide the tapes containing those.  I didn't have to go through multiple separate, successive restore jobs for each parent backup in the set leading up to the one I wanted.  That would mean the restore process would only write out the data contained in that specific backup, and that design still doesn't make any sense to me at all, because to the point you made in your original post, that would mean that if I accidentally skipped an Incremental or something in my multi-part restore, that error of omission would likely result in a bunch of files on the target being corrupt because they were missing some pieces from the backup I skipped.  That doesn't seem like any way to design a backup application.

My point about an empty drive didn't mean that what I described was limited to an empty drive scenario.  I only mentioned that because you asked about that scenario.  Again, the overarching design logic is that you select the point in time you want to restore your partition(s)/disk(s) to, and Reflect will do whatever needs to be done on the target partition(s)/disk(s) to get you there, regardless of whether that involves writing out the entire contents of the backup because the target is currently empty, or using RDR to simply alter the current state of the target to make it match the state of the backup you chose to restore in order to avoid having to blow away everything on the destination and writing everything out from scratch.  Or if you want to disable RDR, you can have it do that instead.

Edited 11 February 2020 11:47 PM by jphughan
twgonder
twgonder
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)
Group: Forum Members
Posts: 18, Visits: 45
jphughan - 11 February 2020 11:44 PM
Well with a tape strategy, you generally don't have all of the necessary backup data available simultaneously as you do with Reflect when all backups are sitting in the same folder of a hard drive or network share.  But at least when I was working with tapes, I remember that I could choose to restore an Incremental backup, and if the application needed the parent backups, it would prompt me to provide the tapes containing those.  I didn't have to go through multiple separate, successive restore jobs for each parent backup in the set leading up to the one I wanted.  That would mean the restore process would only write out the data contained in that specific backup, and that design still doesn't make any sense to me at all, because to the point you made in your original post, that would mean that if I accidentally skipped an Incremental or something in my multi-part restore, that error of omission would likely result in a bunch of files on the target being corrupt because they were missing some pieces from the backup I skipped.  That doesn't seem like any way to design a backup application.

My point about an empty drive didn't mean that what I described was limited to an empty drive scenario.  I only mentioned that because you asked about that scenario.  Again, the overarching design logic is that you select the point in time you want to restore your partition(s)/disk(s) to, and Reflect will do whatever needs to be done on the target partition(s)/disk(s) to get you there, regardless of whether that involves writing out the entire contents of the backup because the target is currently empty, or using RDR to simply alter the current state of the target to make it match the state of the backup you chose to restore in order to avoid having to blow away everything on the destination and writing everything out from scratch.  Or if you want to disable RDR, you can have it do that instead.

Ha ha, backup application? I was the backup application. All we had was a backup command that did just that, backed up and nothing more. Same with the restore command. We had organized tape racks and log books. So yes, fragmentation was a real problem if there was an error in order or of omission. For the younger users to get an idea of the environment we used to work in, when we ported the super-mini version of the O/S to PCs in the 1980s, the entire system fit on seven 1.2MB floppy disks.

Anyways, curiosity got the better of me, after the last weekend of endless restores and problems. For those that are curious, I deleted most everything on a test drive that I have (F: ). Then I added a directory. Then I did a restore from an incremental. In one screen shot you can see all the files of backups were processed. Again so cool and what I would expect from a modern application (but had my doubts.) Also good to note that the new directory was removed.

I did a lot of reading of Macrium's help files last weekend. Not once did I see any mention that all you needed to select was the most recent backup file to get a complete restore. If it was said, it was in such a way that I didn't understand what they were driving at.

As a final note, at least one other user claimed (as did I) that doing RDRs on the Windows partition seemed to cause problems. I know for sure it did because users that I created after the backup showed up after the restore on the logon menu. This could be creepy Windows stuff trying to automatically patching "errors" from goodness knows what secret locations they might store stuff or limit Reflect's access. So even though the RDR restore here seemed to work okay on a non windows partition, if you have creepy problems  with restores, you might consider disabling an RDR restore in the advanced menu of the restore.
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)Macrium Evangelist (8.8K reputation)
Group: Forum Members
Posts: 6K, Visits: 45K
If I had to guess, I suspect the reason it wasn't explicitly mentioned that you could restore directly from the desired backup was because that was simply always the case with Reflect and most users would simply assume that without it being explicitly stated.  I'd certainly expect the documentation to indicate that you couldn't do that if you did in fact have to restore in the "legacy" manner you describe, but otherwise this to me falls into the category of, "Given how few people will actually read the amount of documentation we have, how much larger do we want to make it by stating the assumed/obvious?" category.  But of course what some consider obvious others wouldn't.

I'd still be curious to see if you can reproduce the claimed RDR behavior on a system where you aren't redirecting user profiles to a different volume, or really on any type of clean system since it sounds like the one you've been working with has quite a few strange things going on.  It would be easy enough to simulate in a VM by booting it from a Rescue Media ISO.  If you're truly convinced that you've found a bug, then it would absolutely be worth reporting to Macrium Support, since after all proper restores are a crucial function of any backup application and RDR is enabled by default, so a bug of that nature would be critical.  But of course a proper actionable bug report would ideally involve a clear description of test conditions and clear steps to reproduce, not just a general summary of something you saw when you did something on a system that had some dependencies on a partition you didn't restore and also apparently had some issues.  But failing that type of report, I personally think it's inadvisable to claim without clear evidence on a public forum that the default restore mode of a widely used backup application doesn't work the way it's supposed to.  The empirical data is overwhelmingly against that claim, and it's apt to cause consternation that may prove unwarranted if your experience turns out to have some other explanation -- including user error.  This hasn't happened to me often, but it HAS happened to me that I've been absolutely certain that I did one thing and it later turned out to be irrefutable that I in fact did some other thing, my certainty to the contrary notwithstanding.  I have personally helped at least one person on this very forum who couldn't understand why his post-restore system state was the way it was.  He ran the restore multiple times hoping to fix it.  The underlying cause of the issue turned out to be that on all of his attempts, he was restoring a backup that he thought had been made on one date when in fact the backup he had been restoring had been made on a different date.  And if you're not willing to try to reproduce the behavior you're alleging here, I don't believe even an explanation like that could be ruled out.

But of course that's all just my opinion.

And just from a technical perspective, an image restore isn't a file-level operation where in theory some files might have been left on the target rather than being deleted.  It's a block-level operation, and it also restores the partition's file system.  The idea that you could perform an image restore operation that somehow left some pre-existing files on the target intact and also restored the file system in such a way that it accounted for all of the restored data as well the pre-existing files just doesn't seem reasonable.

Edited 12 February 2020 2:35 AM by jphughan
twgonder
twgonder
New Member
New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)New Member (20 reputation)
Group: Forum Members
Posts: 18, Visits: 45
jphughan - 12 February 2020 2:16 AM
If I had to guess, I suspect the reason it wasn't explicitly mentioned that you could restore directly from the desired backup was because that was simply always the case with Reflect and most users would simply assume that without it being explicitly stated.  I'd certainly expect the documentation to indicate that you couldn't do that if you did in fact have to restore in the "legacy" manner you describe, but otherwise this to me falls into the category of, "Given how few people will actually read the amount of documentation we have, how much larger do we want to make it by stating the assumed/obvious?" category.  But of course what some consider obvious others wouldn't.

I'd still be curious to see if you can reproduce the claimed RDR behavior on a system where you aren't redirecting user profiles to a different volume, or really on any type of clean system since it sounds like the one you've been working with has quite a few strange things going on.  It would be easy enough to simulate in a VM by booting it from a Rescue Media ISO.  If you're truly convinced that you've found a bug, then it would absolutely be worth reporting to Macrium Support, since after all proper restores are a crucial function of any backup application and RDR is enabled by default, so a bug of that nature would be critical.  But of course a proper actionable bug report would ideally involve a clear description of test conditions and clear steps to reproduce, not just a general summary of something you saw when you did something on a system that had some dependencies on a partition you didn't restore and also apparently had some issues.  But failing that type of report, I personally think it's inadvisable to claim without clear evidence on a public forum that the default restore mode of a widely used backup application doesn't work the way it's supposed to.  The empirical data is overwhelmingly against that claim, and it's apt to cause consternation that may prove unwarranted if your experience turns out to have some other explanation -- including user error.  This hasn't happened to me often, but it HAS happened to me that I've been absolutely certain that I did one thing and it later turned out to be irrefutable that I in fact did some other thing, my certainty to the contrary notwithstanding.  I have personally helped at least one person on this very forum who couldn't understand why his post-restore system state was the way it was.  He ran the restore multiple times hoping to fix it.  The underlying cause of the issue turned out to be that on all of his attempts, he was restoring a backup that he thought had been made on one date when in fact the backup he had been restoring had been made on a different date.  And if you're not willing to try to reproduce the behavior you're alleging here, I don't believe even an explanation like that could be ruled out.

But of course that's all just my opinion.

And just from a technical perspective, an image restore isn't a file-level operation where in theory some files might have been left on the target rather than being deleted.  It's a block-level operation, and it also restores the partition's file system.  The idea that you could perform an image restore operation that somehow left some pre-existing files on the target intact and also restored the file system in such a way that it accounted for all of the restored data as well the pre-existing files just doesn't seem reasonable.

You are right on many points, but I do know a few simple facts. I created the new users on C after the backup because I wanted them there in case I got locked out again with bitlocker on D. More problems ensued and I did a restore again. The users showed on the logon menu while one user I deleted returned (as expected). I can't remember all the other events because I was a bit frantic (and foggy headed from lack of sleep and reading documentation/tech forums) about losing some important user data, and just getting a system back. But when those users appeared in the logon menu, I was clear headed enough to stop and consider well what I was seeing. Also, my D drive was fine before the backup, or Reflect would have reported errors, as it did after the restore when another backup was attempted. Nothing I would have done would have corrupted the file system so horrendously, as all I was using at that point was Reflect. The drive checks out fine after a non RDR restore.
I said: ...if you have creepy problems with restores, you might consider ... I made a simple suggestion that others have echoed. It's not an incrimination, simply a suggestion that can be ignored if you're 100% confident in RDR. I also stated that the problems might have been induced by Windows doing its own creepy things after the restore (but that doesn't explain what happened on the D drive).

I wish I had the time and spare equipment to do all the different experiments that one could imagine. I admit I didn't start with a "clean" system, as the 1903 update did some horrible stuff (that I can't reproduce) before the restores. The horrible stuff didn't vanish after doing the restores. If it had, I wouldn't have lost my weekend doing RDR restores, and then finally, by disabling RDR, I got my first of maybe ten restores to reliably restore a clean system. Also, as mentioned earlier in a different thread, I had a similar problems with a RDR restore on a different computer about a year ago, and it was Macrium tech support that suggested disabling RDR. Also, you need to consider that the recovery builds were from a long time ago when Reflect was first installed, are you sure those were bug free as to RDR?
Cheers and thanks again for all your insights .
Edited 12 February 2020 4:07 AM by twgonder
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search