Hi, On 5/31/2007 8:09 PM, Doug Breshears wrote: > Arno Lehmann wrote: >> Hi, >> >> On 5/31/2007 2:41 AM, Doug Breshears wrote: >> >>> Hi All, >>> >>> I have successfully upgraded to version 2.0.3 and have implemented a >>> migration scheme where backups are first backed up to "File" storage and >>> then a migration Job is called to migrate them to tape. >>> >>> This will solve the issue of forgetting to insert tapes and having the >>> backup jobs run during the day, interrupting all manner of processes. >>> >>> The one problem I am having is that the "Volumes" on the file storage >>> are not getting removed after the migration is complete. >>> >>> The test runs that I have done verify that the volume does not get >>> migrated again so it is marked as already migrated, >>> >> Not quite... Bacula does not migrate volumes, but jobs. Consequently, >> volumes are not marked as migrated. >> >> >>> but the docs that I >>> read (www.bacula.org/dev-manual/Migration.html) say that "The original >>> Job is purged of its file records". >>> >> It better would, because Bacula currently has no idea what to do when >> multiple copies of the same file from the same job exist. >> >> >>> I took that to mean that the >>> original data would be wiped. Maybe it just means the database records?? >>> >> It definitely means that. >> >> >>> Is there a way to cause this to happen automatically? >>> If not is it safe to just delete the "Volume" files after a migration? >>> >> No, you have to delete the corresponding catalog records, too. >> >> >>> Or do we have to manually purge them in the console, then delete? >>> >> Yes. Although it might be simpler to leave them and reuse them for >> future jobs. >> >> Arno >> > Arno, Martin: > Thank you both for the help, you are great. > > My only issue with leaving them there is file space. If I run out of > space on the HD partition due to old migrated jobs, the backup will stop > until morning when I am able to fix the problem. Which is what I am > trying to avoid. > Is bacula smart enough to fix this on its own?
If you configure it smartly :-) The key is to configure the disk pool retention times correctly, and make sure there are volumes available for recycling. The latter is rather simple, if Bacula works as I think it should: After the jobs are migrated to tape, they no longer block the disk volumes. So, whenever Bacula looks for usable volumes, it should be able to recycle these. The setup of the retention times is simple when Baculas pruning algorithm runs perfectly - once there are no more jobs on a volume, they should be eligible for recycling even when the volumes retention time has not yet passed (Admittedly, I'm unsure if that works as I described it. Up til the development version, afaik, Bacula might have needed two passes in looking for a new volume to recycle such a volume). So, it would be helpful to make sure the retention time of the volumes expires *after* the jobs are migrated off it, but *before* the new jobs start. That, obviously, can be tricky if you don't have spare volumes, because slight changes in job execution can screw up your volume use cycle. I can only recommend to keep the retention times on the safe side, i.e. rather long, and observe what happens. I don't have a comparable setup to test this myself, but I would really like to see your results :-) > I am using 3 pools (daily,weekly,monthly) and I have extended those to > the HD File storage as well (daily-file, etc..) so that the migrate jobs > could get them on the correct tape pool. The problem this causes is that > after a month there will be 3 sets of files that are waiting to be > reused but still taking up space. Well, I think having spare space for backups is always a good thing, so I wouldn't consider that as a problem... unfortunately, if you already reach the limits of your disk space, that is a problem (which will, typically, only become more serious with time, because most backup sets grow in size in my experience...) > > Any Ideas? Currently, I can only recommend to try if Bacula works as it - in my opinion - should. If it doesn't, you'll have to spend some time, but approaching things carefully you would not lose any backups. If things don't work out, and you need a solution before a version of Bacula is available that recycles more smoothly (which is currently in developmen, I believe) you could implement a script that does the necessary steps outside of Bacula: Determine which volumes are empty (a simple SQL query), feed input to bconsole to puge these volumes, or to delete them from the catalog and delete the corresponding disk files. Anyway, I guess it shouldn't be too hard to get what you need. Arno > > Doug > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
