Holger Parplies wrote:
>>> [...] what's the point of having both full and
>>> incremental backups?
>> The difference is just in time, cpu use, and network bandwidth for the
>> backup runs to complete. [...]
>> If you have the bandwidth and time for all backups to complete, there's
>> nothing wrong with doing fulls every night.
>
> I think you are missing an important point: disk wear. We're not talking
> about 5% more or less time. On an example host (which may or may not be
> typical), I see a full backup taking 20 times as long as an incremental. The
> *full* takes 1-2 hours, so there's plenty of time to spare, but why would I
> want my disks on both BackupPC server and client machine to spend 1-2 hours
> each night seeking all over the place, when a few minutes for an incremental
> backup will satisfy my data security needs?
I've never observed any relationship between disk activity and disk
failures. More use won't noticeably shorten their life, although you
might detect the bad spots sooner than if you don't read all of it
during backups.
> Incremental backups are a compromise, but in most cases an extremely good
> one, more so for rsync than tar/SMB:
>
>> With tar and smb incrementals you may miss files that
>> have been copied or moved in ways that preserves an old timestamp
>
> ... which is any 'mv' or 'cp -p' (or equivalent operation), including
> directory renames.
On unix/linux, mv/cp/etc. will change ctime and tar will catch them even
if mtime is preserved. It won't get the new location of old files under
a renamed directory. With smb, you'll also miss mv's etc. since you
only see mtime. (Ctime is the inode modification time and is supposed
to change as the link()/unlink() operations of mv change the link counts
- but I think some linux file systems have gotten that wrong in
rename().)
> tar/SMB also cannot detect that files have been deleted,
> so they will be present in backups upto the next full.
And this could result in a set of files too large to restore in the old
space if your filesystem is very active.
> rsync is harder to fool. You need to modify a file, keeping file size and
> modification date as they were (this can be done, for instance, by swapping
> two files of identical size and modification date with three 'mv' commands).
Try it. On unix I think the ctime modification will catch this. If it
doesn't I'd consider it a bug. It might be missed on windows, though,
and some unix-like systems have ways to reset ctime.
> Chances are, this will happen next to never, but if you determine it is
> common enough to worry about at your site, you will have to figure it in.
>
>> rsync becomes less efficient as you get farther away from a full run.
>
> ... as do tar/SMB in exactly the same way. All changes relative to the
> reference backup need to be transferred. While this may still be faster than
> a full backup, the sum of (1 full backup + (N-1) incremental backups) will
> take less time than (N incremental backups) for an ever decreasing value of
> N. So, an occasional full backup will give you increased accuracy for free.
>
> As for incrementals of increasing level (meaning more recent reference
> points than the last full), the effort of constructing the backup view (i.e.
> reference point) grows with the level, so you can't do randomly high level
> incremental backups, even if your data security requirements would permit it.
I think a good compromise here would be to add an optional multiplier or
time window setting instead of setting --ignore-times for every rsync
full. That way you could say to do the full check every 10th full, or
only on weekends but still have the backuppc tree reconstructed more
often than that.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
