Expanded F&F restore options


Author
Message
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 64K
I realize that with Macrium tbFAT having removed the limitation related to mounting F&F backups containing files larger than 4GB, there may be fewer use cases for using the Restore wizard.  But it is still certainly the easiest way to restore custom NTFS permissions when needed, and therefore I would suggest two additions to the restore options in the wizard.  The first was originally suggested for V7.  The second is the result of a test I just performed.

  • Restore only files that are missing.  Suppose a user discovers that some files went missing, but might realize they don't know exactly how MANY files are missing in a potentially complex folder structure.  (Or more realistically, an IT support staffer might receive a request of this nature in relation to a file server.)  The files are restored from a known good point in time, but several OTHER files have been modified in the meantime that should not be reverted.  It might be nice to have a way to have the Restore wizard restore only files and folders that are missing, leaving all other files unchanged.  Otherwise, recovery from this scenario would entail restoring the backup to an alternate location, then running a folder compare to find files unique to the restored location.  But then you don't get the benefit of restoring custom NTFS permissions on entire folders that may have gone missing.
  • Delete files at the destination that are not in this backup. I realize this one could be hazardous especially if the job that created the backup in the first place had exclusions defined.  But not everybody uses those.  And currently, it seems impossible to use an F&F backup to return the original location to its exact state at the time of the backup, which would include deleting any content created since that time.  Of course one could simply delete all existing contents at the location prior to performing the restore, but that would also extend the restore time, potentially significantly, since some of those deleted files may not have even changed since the time of the backup being restored, and therefore those files could have been left intact.


JK
JK
Advanced Member
Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)
Group: Forum Members
Posts: 255, Visits: 690
> Restore only files that are missing

Does the restore wizard not have any option to "Don't overwrite files that are newer"?  That should accomplish the same thing, no?

This option (however it is named) is essential, and is a standard feature of many/most other file backup programs.
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 64K
No, the only current options are "Replace all files" and "Replace files that are different".

JK
JK
Advanced Member
Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)
Group: Forum Members
Posts: 255, Visits: 690
That's unfortunate.  In my opinion, this (control over how/whether to restore when the file already exists) is critical functionality in file backup software, and for many potential converts from other backup products, this may be a deal breaker.

I think that an option to not overwrite existing files if they are newer would capture your requested functionality to restore only files that are missing, while also accommodating additional use cases.

I believe that the reason such control is not (yet) available in Reflect may be related to the fact that they do the file backups at the level of blocks, not at the file level.  So it would probably be difficult to figure out which file each block originally came from, and the information about last modified date of each backed up file is probably not even captured in the backup (although a compromise functionality would be an option to not overwrite existing files if they are newer than the date of the backup, rather than the date of each individual file).

Nonetheless, individuals who want to use this more granular restore option would probably not mind some modest performance penalty during the restore phase, when they select options that require Reflect to identify the individual files being restored.
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 64K
I may be wrong, but I don’t think blocks are a limitation. F&F backups decide whether a file has changed by looking for a difference in size and/or Date Modified. If neither has changed, as can optionally be achieved with VeraCrypt containers, then Reflect F&F backups would not notice changes. But after Reflect has determined a file has changed, at THAT point it seems to only back up changed “cluster runs” just to save space. But I don’t think that would preclude the extra restore options. As long as Reflect had a record of the size and Date Modified timestamps of each file in each backup, even if it only had a fragment of that file in that specific backup, those restores should be possible.
JK
JK
Advanced Member
Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)Advanced Member (417 reputation)
Group: Forum Members
Posts: 255, Visits: 690
F&F backups decide whether a file has changed by looking for a difference in size and/or Date Modified.


I guess the question is whether this info (Date Modified in particular) is saved in the index that is embedded in each .mrbak file. 

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)Macrium Evangelist (15K reputation)
Group: Forum Members
Posts: 10K, Visits: 64K
It seems to me that it would have to be. Otherwise how would Reflect know if the file’s current size or Date Modified timestamp is different from the version of that file in the most recent existing backup? I guess Date Modified could be compared against the date of the entire backup, though that intuitively seems riskier somehow, but that wouldn’t work for size, and if a backup only contained a fragment of certain files, you couldn’t determine size of the entire file by counting blocks in just the most recent backup either, even ignoring the performance overhead of that. So storing at least size information in the index seems like the logical choice.
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