Martin, (sorry for the delay; I was traveling)
I suspect you're right. Here's the output of that query for reference: > > select jobid,count(*) from File where jobid in > (181371,181679,182032,182350,182668,182718,183093,183408,183724,184039,184354,184669,184984,185615) > group by jobid > -> ; > +--------+----------+ > | jobid | count(*) | > +--------+----------+ > | 181371 | 11703 | > | 184354 | 4 | > | 185615 | 11703 | > +--------+----------+ > 3 rows in set (0.01 sec) > > > There is something weird with 185615, that I can't explain right now. But other than that, 181371 is the initial full, and 184354 indeed has 4 files in it. The rest do indeed have zero files in them. I'm still not sure what's going on. But I've manually run VFs (not progressive VFs) for all the jobs in question, and modified the mounting script to guarantee that at least one file will be changed in every incremental. It'll take a while to build up the history to start the PVFs again, but hopefully this workaround will fix it. Lloyd On 10/1/19 8:08 AM, Martin Simmons wrote: > I think the fatal error is that it can't find records in the File table for > any of the JobIds that it is consolidating. > > Have the file records for those jobs been pruned? You could check with an SQL > query like this: > > select jobid,count(*) from file where jobid in > (181371,181679,182032,182350,182668,182718,183093,183408,183724,184039,184354,184669,184984,185615) > group by jobid; > > __Martin > > >>>>>> On Mon, 30 Sep 2019 13:09:54 -0600, Lloyd Brown said: >> Hi, all. >> >> I may be misunderstanding (or misconfiguring) something again. I'm >> hoping someone can explain it to me. >> >> I'm trying to set up a progressive virtual full scheme. But in several >> instances, the incrementals that would be consolidated by the VF, are >> empty, meaning that the VF is failing with errors like this: >> >>> 30-Sep 08:25 backup-dir JobId 221077: Start Virtual Backup JobId >>> 221077, Job=zhome_sw.2019-09-30_08.25.06_37 >>> 30-Sep 08:25 backup-dir JobId 221077: Consolidating >>> JobIds=181371,181679,182032,182350,182668,182718,183093,183408,183724,184039,184354,184669,184984,185615 >>> 30-Sep 08:25 backup-dir JobId 221077: No files found to read. No >>> bootstrap file written. >>> 30-Sep 08:25 backup-dir JobId 221077: Found 0 files to consolidate >>> into Virtual Full. >>> 30-Sep 08:25 backup-dir JobId 221077: Fatal error: Could not get or >>> create the FileSet record. >> Now this is correct. While there are files in the initial full, there >> are indeed zero files in those subsequent incrementals. But why is that >> a fatal condition? >> >> The result of this being a fatal error, is that my existing full remains >> at its original date/time Therefore, it will eventually reach the >> retention period age, and be pruned. Then I have to start over with a >> complete, non-Virtual Full again, and lose a few months of backup >> history that would otherwise be usable. >> >> If there's a way of changing this behavior via config file, that would >> be great (current config example attached). >> >> I do also have a workaround in mind. I'm just trying to understand if >> I've done something wrong, and if not, what the reasoning was about this >> being a fatal error. It was certainly unexpected. >> >> This is running on Bacula 9.4.3. >> >> Thanks, >> >> Lloyd >> >> -- >> Lloyd Brown >> HPC Systems Administrator >> Office of Research Computing >> Brigham Young University >> http://marylou.byu.edu >> >> > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
