Hi, 29.10.2007 23:03,, Michael Lewinger wrote:: > 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.
Right. > 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... This is about what the feature request no. 1 is about, as found in the current projects file. The thing Mike wrote about is, as far as I understand, covered by the featore request 3, "Synthetic Full Backups". You only do incrementals, and Bacula, internally, rearranges the files stored so that you always have a recent full backup available. Both feature requests result in two different ways to allow exact full restores - the one requires less work by the DIR but will need many jobs and hence volumes during a restore; the other one loads the DIR and SDs more but ensures you have a recent full backup on your volumes even if you only ever run incrementals. Base jobs are different again - they will (once implemented) allow a "template" backup of a machine to be created, and use this templare for other clients. Like when you run the same OS on all your servers, you have to back up the base OS only once and all clients are covered by it. Only changes against that base file set need to be loaded from the clients, even if running full backups. (I think that these three things will have lots of behind-the-scenes action in common, so I assume they will be implemented more or less at the same time - once somebody starts working on them.) Arno > Michael > > On 10/29/07, *Mike Eggleston * <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > On Mon, 29 Oct 2007, Michael Lewinger might have said: > > > The perpetual backup, maybe that's only how I think of what TSM > does, backups > up a file from the client to the server and keeps a TSM admin > defined (even > per client defined) number of versions of that file before the > oldest version > falls off the back. If the file is deleted on the client, the TSM server > keeps at a minimum the last, most current version of the deleted > file for X > number of days before that file falls out of the TSM server. The > first time > a client is backed up, all the files defined for that server are > backed up. > Each time after unless the admin or some schedule specifies, only > changed > files are copied. There is no need for a Full. Though some sites do a > periodic or monthly full, you can setup the TSM server for > incremental forever. > My issue right now is that my tape drive is so slow that I want only the > incrementals and not the fulls. > > Mike > > > > > -- > Michael Lewinger > MBR Computers > http://mbrcomp.co.il > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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
