Hi, Les Mikesell wrote on 11.11.2007 at 12:24:16 [Re: [BackupPC-users] Full or Incremental.. What's the point?]: > Gene Horodecki wrote: > > [...] what's the point of having both full and > > incremental backups? > > > > [...] But with the > > awesome efficiences offered by BackupPC, it seems to me incremental/full > > becomes a mute point and a person might as well do an incremental every day > > perminently, or a full every day if you're worried about missing files with > > the incremental.. Either way, it's going to use the same amount of storage > > is it not? > > 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? A full backup at the file level is never a linear disk operation, but even less so on the BackupPC server end, where file layout is optimized by the file system to fit the first backup rather than the current reference backup (and even that ignores files shared among clients or within one backup). The foremost concern are your requirements concerning backup correctness. Only a full backup is guaranteed to get an identical image of your file system, and that only if you have a snapshot mechanism on the client machine. Lacking that, incremental backups may, in fact, save a more consistent system state. 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. tar/SMB also cannot detect that files have been deleted, so they will be present in backups upto the next full. 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). 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. Regards, Holger ------------------------------------------------------------------------- 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/
