On 15.09.2017 at 17:54 wrote Douglas K. Rand: > On 09/15/17 10:51, Jörg Steffens wrote: >> On 15.09.2017 at 17:03 wrote Douglas K. Rand: >>> I screwed up my migration to Always Incremental backups, and I'm hoping >>> that there is a path back for me. I had been doing a classic >>> incremental, differential, and full set of backups to disk. When >>> switching to AI backups Bareos noticed that there was a full backup >>> available, and then just continued to use that. Which is way cool. >>> >>> And also use the incremental and differential backups also. When >>> consolidation jobs ran it just did the right thing. Until my screwed up >>> config caught up with me though. >>> >>> I was only retaining the incremental backups (not the AI backups, but >>> the original incrementals) for 18 days. And differential backups for 21 >>> days, and full backups for 28 days. But when deploying always >>> incremental I set: >>> >>> always incremental job retention = 30 days >>> always incremental keep number = 10 >>> always incremental max full age = 38 days >>> >>> Which means it won't run consolidation until there are 30 days of >>> incrementals, but I was only keeping the old ones for 18 days. >>> >>> How did my original testing succeed you ask? Good question! Because I >>> had somehow disabled pruning when originally setting things up. And did >>> my testing when nothing was being pruned. Then I noticed my database was >>> HUGE and catalog backups kept getting bigger. So I turned on pruning. >>> And then consolidation jobs started to fail. >>> >>> Gun, meet foot. Sigh. >>> >>> Is there a way back from this? I've extended all of my retention >>> periods to 40 days and turned off auto pruning. But damage has been >>> done. >>> >>> Help please. >> >> As long as your volumes are only pruned, but have not been overwritten >> (or truncated) you can probably rescan them into the catalog. >> >> First you have to prevent, that "empty" volumes get overwritten. >> (set volstatus to Archive? Attention: retention times from the pool >> configuration are assigned to the volume upon first use. You have to use >> the update command to reassign the new settings from the pool >> configuration) >> >> Second, check the contents of the volumes using "bls" >> >> Third, use bscan to read the data from the volumes and add them to the >> catalog again. > > Thanks Jorg. Is there a way to have the consolidate jobs somehow > ignore the missing jobs,
missing jobs shouldn't be a problem, as long as you have your full and use the accurate option. Using accurate, Bareos should be able to catch all the differences. > and in some case jobs with no files in the > catalog, and moving on? I'm not sure how this behaves. I think I have seen a bug report about something like this. > Or do I have to bscan the few hundred volumes? No, this is only required if you want to restore the backup jobs. As a side-note: " When using the always incremental scheme, the volume retention should never be used or needed to reuse a volume: The migration jobs will automatically remove sucessfully migrated jobs from the Database and so the volume will automatically be empty when all jobs are migrated away from it. " -- Jörg Steffens [email protected] Bareos GmbH & Co. KG Phone: +49 221 630693-91 http://www.bareos.com Fax: +49 221 630693-10 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Komplementär: Bareos Verwaltungs-GmbH Geschäftsführer: S. Dühr, M. Außendorf, Jörg Steffens, P. Storz -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
