On Tue, 30 Oct 2007, Michael Lewinger might have said: > Hello Mike, > > What you are talking about is regular practice, and is what is attained by > the "incremental" feature, so I guess that TSM and bacula are the same > there. The first time it is run, an inc. backup will be promoted to full, > and afterwards, only inc. will be performed. Good backup practices demand > that a full backup be performed at least once a month in case a tape fails. > > HOWEVER once a file is deleted, it will only be effectively removed from a > restore when a FULL backup takes place thus skipping it (it was deleted, > right ?). Until then, post-deletion recoveries will produce the deleted > file, updated to its latest version. (duh). In practice, until you do a > second full backup, you'll keep recovering long-ago unnecessary, deleted > files, hence the need for some full backup policy. It would be easier on a > slow network to recreate full backups using MD5 and files already present in > bacula's volumes but this would complicate tape maintenance enormously. The > keep-number-of-files feature is interesting though, as an alternative to > date-based retention times. AFAIK bacula does not have this feature. > > Maybe - this is a BIG maybe - there should be an option of reusing already > stored files, and make full backups assembly on slow networks: 1) check MD5 > on client, 2) Compare file identity to file table on catalog 3) HEY, I have > this file already ! Let's make a list of volumes necessary, and ask the user > to supply us the required volumes, 4) Spool the reused files (as if they > were d/l) 5) Voila ! > > It looks to me this is the "base" backup level, but until more of this > feature shows up on the docs...
Just occurred to me, if I change the primary schedule so that Fulls are pulled quarterly or every six months (bi-annually?) then I am closer to the perpetual incremental. I understand a failing tape and am looking at external drives that I can use for sending off-site instead of nine DLT-8000 tapes. The external drives I'm looking at are around $200 USD each. Changing bacula so that it tracks files instead of jobs I bet is a major paradigm shift inside the code and not to be started lightly. I think the per-job approach might be better for small sites (lesser amounts backed up) and the per-file approach might be better for larger sites (lots of files or data backed up). I have modified my setup so that I am using disk based volumes for my nightly backups, then after all the primary nightly jobs finish I have a single job that grabs all recently modified disk-based-volumes and writes them to tape. The real epiphany to my setup was realizing I could use bacula to manage the final disk-to-tape job instead of writing my own script. TSM does all the file checking before hand and on windows (and on AIX, but last time I used TSM it didn't work well there) you have the option have having a client-local journal file of backed up files. The local client gets the backup specification, generates a list of files, compares that list of files to the journal file, and only sends over the network the files that have truely changed. Without the local journal file the client and server must discuss each file to see if the client needs to send the file to the server. Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
