mattengland Posted January 5, 2009 Report Share Posted January 5, 2009 (edited) 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 January 5, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 5, 2009 Report Share Posted January 5, 2009 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 Quote Link to comment Share on other sites More sharing options...
rhwalker Posted January 5, 2009 Report Share Posted January 5, 2009 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.