[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread    

Number   :  3693
Date     :  2003-02-12
Author   :  jamesvmerrill
Subject  :  Re: "True" Incremental Backups
Size(KB) :  4


It should be possible to create some software that would do what you 
want here, but I agree that it would be quite nice if XXCOPY allowed 
(as you suggest) specification of multiple base directories that 
could be unioned together to form the list of target files against 
which the source is compared. (When working in that mode, no 
deletions from the target would take place -- right?)

The software I'm imagining would run XXCOPY in /L (don't copy any 
files) mode, generating a file naming the files that would have been 
copied to the target, and those that would have been deleted from the 
target, had /L not been specified. It would parse that file, and 
move any files named there (that exist -- those representing new 
files would not) to a path named based on the date. (That would 
preserve "yesterday's" incrementally backed up files.) Then it would 
run XXCOPY again without /L to actually back up "today's" changes.

The biggest flaw with this, conceptually, is that if you decide to 
revert to a point (say) 10 days after your first ("full") backup, and 
you do so by copying the contents of your full backup back, followed 
by your day-1 incremental, your day-2 incremental, etc -- you will 
end up with every file that you ever had at end-of-day. That is, 
none of the file deletions that you had done would be in effect, and 
thus you could possibly end up with a situation where there isn't 
sufficient space on your original drive. Even if you don't run out 
of space, you've got all the "junk" you deleted along the way back 
again, lucky you. Only by recording the full contents of your source 
directory each day could you automate the deletion of junk files that 
had been copied back from the intermediate incremental backups. (But 
perhaps you would plan only to copy individual files back from 
incremental backup, and not do it "in bulk" with everything.)

That problem exists even in high-end backup software when you use 
incremental backups. To restore, you restore the full backup and 
each incremental in sequence; nothing is ever deleted and you get 
lots of junk. 

Some high-end backup software (in their documentation and via their 
support personnel) deprecates incremental backups in lieu of 
differential backups. That is, after your full backup, each day you 
back up any changes since the full backup -- not just those made that 
day. When you restore, you need only pick the single differential 
backup you want (by date) to restore. When the differential backup 
gets too large, do another full backup and remove your 
differentials. (But then you can't go back to a date prior to the 
full backup.)

Potentially much simpler would be to do your incremental copy based 
on created- or last-modified date (rather than the delta between 
source and target). Copy anything with a create date after the last 
incremental, then copy anything with a last-mod date after the last 
incremental using XXCOPY's "don't bother if already there" logic.

If you figure out the perfect answer, let us know...

--- In xxcopy@yahoogroups.com, "Jonathan B."  wrote:
> As I understand it, the /BI (backup incremental) option relies on 
the 
> destination directory already having previous versions of the files 
to be 
> backed-up. I'm wondering if it is possible to have a "source" 
destination, 
> distinct from the xxcopy destination, that allows one to have 
a "true" 
> incremental backup that does not overwrite one's full backup.
> 
> My goal is to have an independent backup of the incremental changes 
so that 
> I can rollback to a previous day's backup if needed. In this 
scenario, 
> however, it is not *quite* as simple as providing a single "source" 
> destination to help determine what changes have occurred. Any 
incremental 
> backup directories that would have already been made would need to 
be taken 
> into account. May I propose an additional parameter such as /SD 
> "sd1,sd2,sd3" with the source destination paths ordered by date?
> 
> If anyone has some great tricks up their sleeve that basically 
accomplish 
> the same thing, please let me know!
> 
> Thanks,
> Jonathan



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.