On 09/15/17 11:17, Jörg Steffens wrote:
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.
Great. Is there an easy way to re-run one virtual job? Or should I just
re-run the consolidation job? If I target the bscan approach I'd like to get
the failed virtual full jobs done.
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.
Ya, 745. The error "Unable to get Job record. ERR=sql_get.c:309 No Job found
for JobId 0" started me down this path. It took me to
https://bugs.bareos.org/mantis/view.php?id=745&history=1. And all of the
"invalid configuration problem" comments made me take a close look, and I
realized my problem.
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.
"
Thanks.
--
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.
