Hi, 04.09.2007 14:43,, user100 wrote:: >> Would this be due to the fact that the file retention period is 30 >> days + incremental saves only since the (only) full backup 2 months ago ? > > I don´t know but if you have a short file retention period and > "AutoPrune" set to yes than the fileentries should be dropped at least > from the database. I´m not sure what happens if you make a new > incremental backup after this time. Maybe the "Jobentry" in the database > get an longer lifetime (Job Retetion) and bacula will get the a filedate > from this entry and still follow with an incremental one (instead a new > full)? If you did not recycle your storage-media in meanwhile the files > are maybe still there but you have to restore them 'manually' (without > database entry).
No... note that the file entries in the catalog have no importance for taking backups, they are only needed to restore files, not complete jobs. When an incremental or differential job is started, it selects files by date only, and chooses files with modification (or creation) times after the last of this jobs run, or the last full job run, respectively. Nothing else, but it does use the file times. ... >> Did the full backup get purged ? >> >> If so, does this mean I have to get a full backup done on a regular >> basis ? Yes, or make sure the full backups are not purged. There are some good reasons to create full backups from time to time: - Only these are guaranteed to pick up each and every file. - It keeps your recovery times lower as you don't have to restore a huge differential backup and/or a large number of incremental backups. - It allows to more or less simple store archival copies of your data. >> >> Sebastian Perkins schrieb: >> >> >> >>Is it possible that you have put the directory to the >> destination in a way that the timestemps did not change? >> I don't quite understand... I'm still slightly newbie :o) >> >> >> Quote from the bacula site >> (http://www.bacula.org/rel-manual/Current_State_Bacula.html#SECTION00540000000000000000): >> "Bacula's Differential and Incremental backups are based on time >> stamps. Consequently, if you move files into an existing directory or >> move a whole directory into the backup fileset after a Full backup, >> those files will probably not be backed up by an Incremental save >> because they will have old dates. You must explicitly update the >> date/time stamp on all moved files (we have a project to correct this)." >> >> This is the reason why we created a program for our windows-clients >> that is checking the files and directories of the backupfolders and if >> it found some file with an archiveflag it remove it and set a newer >> timestemp instead. Not everybody is happy here if the timestemp >> changed but it´s better than have no backup for a long time. Puh... I really don't like relying on the archive flag for backups, as every user can reset that and then your backups might not be complete. As long as you use it as an extra indicator to catch files moved without timestamp updates I have no objections, though ;-) >> However I don´t know if it is the same in Linux. I thought (after a >> few tests) Linux is save :). We don´t use such program or script >> there. So I´m interessted if this could be the reason for your problem. As there is no archive flag on linux' native filesystems - and on no unix filesystem I know - this would not be possible. But how about using extended attributes to store when a file was backed up with which job? (No, this is *not* a serious question...) Arno -- 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
