Nicolas MONNET writes: > To save on bandwidth (I'm using backuppc to backup servers from a > datacenter to my office), I want to run incremental backups as much as > possible. > > I believe it should'nt be too hard to write a tool to transform an > 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 file > 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 = 0, and for incrementals noFill = 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 xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
