On Thu, 2013-12-19 at 12:38 -0500, Dan Langille wrote: > I set my FILE and JOB retentions high. 3 years. Then I set my VOLUME > retention lower. Whichever retention period expires first, that's the > one which counts. <== I will refer to that as 'first one counts' later > in this email. > > Therefore, in your archive pool, set your VOLUME retention to 3 years, > for example. > > And in your main pool, set it to 5 weeks, for example. > > Does that help?
Yes. This is more-or-less what I have now. I have File Retention = Job Retention = 365 days. In the main pool, Volume Retention = 30 days, and in the archive pool, Volume Retention = 365 days. I'm just trying to make sure that this is really going to accomplish what I want. The one big question remaining is how Copy jobs affect this. If I use a Copy job to make a copy of one or more jobs (usually all the jobs for a given client) from the main pool to the archive pool, what happens to the File records? Are there now two File records for every file on the backup? For me that's fine, but in an enterprise setup with thousands of clients, effectively doubling the size of the database would be a pretty big deal, so it wouldn't surprise me to learn that there are some efficiency improvements there. That's what leads me to wonder what really happens when a Volume in the main pool is recycled. The Recycle Algorithm document suggests that the File records associated with that Volume are pruned, so does that or does that not mean that the corresponding jobs in the archive pool no longer have File records? I may have to poke around in the database a little to see if I can answer that question for myself. > > I notice that the paragraph on Automatic Pruning says that you can't > > restore files once the File records are gone, but I know that's not > > true > > because I have done it. I suspect the documentation may be a few > > versions old and I can't necessarily trust everything it says. > > You've done it a different way. Not the 'usual way'. I guess that depends on how you define "the usual way", so I'll clarify. This is what I see, running "restore" out of "bconsole". I first select "most recent backup for a client", and go through the usual process of selecting the client and the File Set, and then I see: You have selected the following JobIds: 56,3603,3609,3616,3622,3710,3716,3722,3832,3839 Building directory tree for JobId(s) 56,3603,3609,3616,3622,3710,3716,3722,3832,3839 ... ++++++++++++++++++++++ For one or more of the JobIds selected, no files were found, so file selection is not possible. Most likely your retention policy pruned the files. Do you want to restore all the files? (yes|no): no Regexp matching files to restore? (empty to abort): At this point, I can type in a regex. Then it shows the usual parameters followed by "yes/no/mod", which I can then modify in the usual way, and then, although it takes quite a while, it will restore the files that matched the regex. > > Does what you've observed make sense when you consider my claim of > 'first one counts'? I'm not sure I can say it makes sense to me until I find some time to poke around in the database to see what is really going on. The one thing I am afraid of is having a Volume in the main pool getting recycled causing the File records for files in the archive pool getting pruned. --Greg ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
