BackupPC-users

Re: [BackupPC-users] Full vs. Incremental (was: Backup through slow line?)

2008-09-06 06:21:57
Subject: Re: [BackupPC-users] Full vs. Incremental (was: Backup through slow line?)
From: Holger Parplies <wbppc AT parplies DOT de>
To: Stephen Vaughan <stephenvaughan AT gmail DOT com>
Date: Sat, 6 Sep 2008 12:20:31 +0200
Hi,

Stephen Vaughan wrote on 2008-09-06 19:11:08 +1000 [Re: [BackupPC-users] Full 
vs. Incremental (was: Backup through slow line?)]:
> What about with multiple full backups, say your full backup is 50gig and you
> do a full backup once a week, will mean each full backup will use 50gigs of
> space? Or does the pool do some other linking between the data contained in
> each full backup?

pooling also works for full backups. Why shouldn't it?

Remember: if you've got a file containing just the word "foo" (or - more
usefully - any other content) and store it in multiple locations, on different
machines, in different shares, multiply within a share, and take as many
backups of all of those machines and shares as you want, you will still only
have one file in the pool to which all of those occurrences are linked -
providing maximum link count permits. Only when you reach $Conf{HardLinkMax} -
31999 by default - occurrences, will a copy of the pool file be created for
the next $Conf{HardLinkMax} occurrences. For reference, 31999 weeks is over
613 years, so if you have no duplication within your data or across servers,
you probably won't be around to see that happen ;-).

What will *not* be shared between full (or incremental) backups is the
directory structure for the pc/<backupnum> trees. The directory tree as such
is identical in a full and an incremental backup, but a full backup contains
directory entries for all existing files, an incremental only for changed
files. A directory with 1000 entries occupies more disk space than an empty
directory. This means that a full backup will in fact use more space than an
incremental - typically only slightly more, but if you have very short files
with very long names, that might be different. Compare the output of 'df' and
'df -i' (on the systems you are backing up, not the pool file system!) or the
BackupPC stats to get a rough idea of your average file size before or after
compression, considering or not considering pooling (actually, you're
interested in the size of compressed new files). Depending on file system and
mount options, storage allocation for files and directories usually happens
in multiples of file system blocks (usually something like 1KB or 4KB), which
is also true for the pool, so even an "empty" directory in an incremental may
take up 4KB of disk space (because it actually contains entries for '.' and
'..' - empty *files* should *not* take up disk space except for the directory
entry).

To summarize, it depends on your setup, and you probably don't need to worry
about it :-).

Regards,
Holger

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/