I'd like to bring this topic back into discussion. I'm trying to keep a
single daily full. To also save on bandwidth, I run a full, and then I
run a daily incremental. I'd like to just merge each days incremental
into the full. Craig, below you discuss that in 3.0+ you were considering
changing the logic used to reference a full that would accomplish this via
finding the most recent filled backup, thus allowing the function of
either keeping an incremental as the most recent Full or possibly having
an option to merge an incremental into the most recent Full?
I'm patient and excited in waiting for the functionality, but was curious
as to if there was a way to accomplish this via command line BackupPC or
other scripting? Has anyone else done so successfully?
I know a manual way is discussed in the below thread, but I'm not sure I
follow it or if all the parts required on present in the discussion.
Thanks for your time,
Brad
From: Craig Barratt <[EMAIL PROTECTED]> - 2006-02-27 01:16
> 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
> possible.
>=20
> I believe it should'nt be too hard to write a tool to transform an=20
> incremental backup into a full backup.
>=20
> * I guess the daemon has to be turned off first
> * Update the "backups" file
>=20
> I've done this by hand, it seems to work, with the exception of the fil=
e=20
> numbers/size being wrong.
>=20
> It's not too much of a problem, I just want to know if there's gonna be=
=20
> 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
is hit.
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
supported.
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.
Craig
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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/
