Hi,
Les Mikesell wrote on 2009-05-22 18:28:21 -0500 [Re: [BackupPC-users] "Full"
backup]:
> Daniel Carrera wrote:
> >
> >> the reference backup for an incremental rsync backup is the
> >> *previous backup of lower level* of the host. Level 1 incrementals
> >> will re-transmit any changed files until the next full backup
> >> (because they are relative to the previous full, not to each other).
> >
> > That seems wasteful. Why is it like that?
>
> The original version only had the timestamp-based tar and smb methods
> and work like more traditional backups. [...]
yes, but the question was: why?
1.) That is what you are requesting BackupPC to do.
If you want your backups to depend on a different reference point
than the previous full backup, you can use IncrLevels. An incremental
backup *can* miss changes. That is highly unlikely with rsync but
remains possible. With increasing level, chances increase. So, doing
*exactly* as requested makes sense.
As with any backup scheme, only full backups are completely reliable.
2.) Backup dependencies
A level 1 backup cannot depend on any other level 1 backup (because this
other backup can - and probably will - expire first). As a consequence,
the backup needs to record any changes since the last full (level 0)
backup. BackupPC would need to take two backups into account, if it were
to use the previous incremental as rsync reference: the incremental (for
the rsync algorithm) and the full (for creating the new backup view). If
a file was "same" as in the incremental, but had changed since the full
backup, it would need to be added to the new backup. That can probably be
implemented (don't know the rsync algorithm well enough to say for sure),
but I wouldn't want to debug it, and I wouldn't feel comfortable about
using it until it had been debugged.
I'm not sure what that would mean for memory requirements considering
large file lists.
> >> The next full will not re-transmit these files (unless they have
> >> changed once again).
> >
> > So it's possible that a full backup runs faster than an incremental
> > because it doesn't have to transmit everything again?
>
> The full itself would take as long -
Wrong. The full can - in theory - be faster than an incremental would be, but
that will only be the case if bandwidth is your limiting factor and your
backup set is relatively small. In my experience, rsync fulls usually take
significantly longer than incrementals because all files need to be read on
client and server and their checksums calculated and compared (one example I
see here has full backups taking at least an hour - for about 25 GB of data -
and incrementals ranging between 4 minutes and half an hour). An incremental
will stat all files and skip those that are apparently unchanged. If you have
100 GB of data in your backup, that will take at least an hour to read on the
client (and probably more on the server with a compressed pool). You can
probably transfer quite some data in that time. If you only have 10 MB of
data in your backup and you can save re-transferring 5 MB over an ISDN link,
it's obviously a different matter.
> but the one following the full
> which becomes the next reference copy could be much faster than another
> incremental based on the older full.
Usually, yes :).
Regards,
Holger
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
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/
|
