Nicolas MONNET writes:
To save on bandwidth (I'm using backuppc to backup servers from a=20
datacenter to my office), I want to run incremental backups as much as=20
I believe it should'nt be too hard to write a tool to transform an=20
incremental backup into a full backup.
* I guess the daemon has to be turned off first
* Update the "backups" file
I've done this by hand, it seems to work, with the exception of the fil=
numbers/size being wrong.
It's not too much of a problem, I just want to know if there's gonna be=
an issue with the pool when the last true full backup gets deleted?
Yes, you are describing one step in what is required to make
"perpetual incrementals" work in BackupPC.
Be aware that except for rsync, incrementals don't pick everything
up correctly since they just check mtimes, so deleted files,
unziped files with old mtimes, renamed files etc aren't detected.
Rsync does the right thing, since all metadata is checked,
including present/deleted. So "perpetual incrementals" are
not recommended for anything other than rsync.
But that said, rsync fulls don't send much data after the
first time, since only checksums are exchanged.
As you know, BackupPC needs a full (or filled) backup to "fill
in" an incremental for browse/restore. There is a flag in the
backups file for "filled" (actually "noFill"). For fulls,
noFill =3D 0, and for incrementals noFill =3D 1. A full backup can
be deleted if the "dependent" incrementals are first filled in
the manner you describe. The field "fillFromNum" should be
set to which other backup is used to fill in an incemental.
It could be a chain of incrementals until a filled backup
Currently the logic for deciding which backup to use as
the reference for an incremental is to simply find the most
recent full. That logic should be changed to find the
most recent filled backup.
For 3.0 I'm considering whether to implement multi-level
incrementals (eg: incrementals can depend upon other
incrementals, instead of the last full). Most of the
pieces are in place, but it's not finished yet.
The second step, which probably won't make 3.0, is doing the
filling you describe to "perpetual incrementals" can be
One other remark: in addition to hardlinking to fill an incremental
you also need to merge the attrib files. Without that new files
won't appear in the browser and deleted files won't be tagged.
The function FillIncr in bin/BackupPC_link should do all of that,
but it's a while since it has been tested.
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
that extends applications into web and mobile media. Attend the live webc=
and join the prime developer group breaking into this new coding territor=
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net