Jump to content
mattengland

"Reverse Incremental" support for disk-based backups?

Recommended Posts

In the Retrospect 7.6.x docs I don't see any mention of needing to rerun full backups (in the Normal/Progressive Backup scheme). I'm hoping this is because it (Retrospect) can support "reverse incremental" backups, as described below, making restore times reasonable even after many successive, Progressive Backups.

 

Can Retrospect do this ("reverse-incremental" backups for disk-based backup sets)? If not, how does one address the restore performance lag due to a "stack of incrementals" that are only stored "forward" (instead of "backward") in time? And/or where can I find out policies and scheduling tricks/suggestions for re-running a full backup?

 

[An aside: This presumably only works for disk-based backup sets, for the "reverse incremental merge" operation on the backend server calls for all the data to be stored in a contiguous device, instead of say storing incrementals on separate tapes.]

 

Confused? See how rdiff-backup works, explained below (aka "reverse diffs").

 

References:

* http://en.wikipedia.org/wiki/Incremental_backup#Reverse_incremental

* http://www.hs4cl.com/2008/07/02/reverse-incremental-backups-and-rdiff-backup/

* http://www.nongnu.org/rdiff-backup/

Edited by Guest

Share this post


Link to post
Share on other sites

Matt, I think that you may misunderstand the Retrospect paradigm, which is completely different from the traditional "full" and "incremental" approach. The difference is best seen during restore, where, with other programs, you have to first restore the full backup, and then each successive incremental in order, so that you end up with the final state of the files that are restored.

 

You have to do a mind reset with Retrospect. The paradigm is that there is a "bit bucket" (the backup set) that holds the files and metadata for the files (permissions, etc.). The backup set is best (and most accurately) viewed as a database.

 

Also, during each backup, a database index is created, telling Retrospect where in the backup set the files presently seen in the source are located in the database (backup set). This index into the backup set is the "catalog", and the present view of the source is represented by the "snapshot" (what files and filesystem trees are present at backup time, and where they are in the backup set).

 

At each backup occurrence, Retrospect backs up whatever is needed to preserve the current state of the source (as filtered by "selectors").

 

With the Retrospect for Windows product, you can "groom" out old snapshots, which will remove the data in the backup set necessary to restore those old snapshots, while preserving data in the backup set necessary to restore ungroomed snapshots.

 

Does this help?

 

Russ

Share this post


Link to post
Share on other sites

Oh, in case it wasn't clear, if you haven't groomed out a snapshot, you can always use Retrospect to go back to that older state of the source, which accomplishes the same thing that you want with a "reverse incremental". You really have to get a different mindset with Retrospect than with other backup programs.

 

Russ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×