You should be able to review the contents of an old bacula catalog dump to find your missing file entries. Be careful not to restore the dump over top of your current catalog. Just to be safe, it would be a good idea to take a fresh catalog backup and *restore it to a safe place* before fooling around with the catalog.
To add to what Bill and Marcin have said: There are default file, job, and volume retention periods hardcoded into bacula. I don't know what the defaults are, and I suspect that the manual is inaccurate when it states the defaults. If I recall correctly, the manual says File retention: 90 days Job retention: 180 days Volume retention: 365 days. Any file or job retention specified in the client resource overrides the hardcoded defaults. Any file, job, or volume retention specified in the pool resource overrides values specified anywhere else. For this reason, I specify my file, job, and volume retention to be the same value as each other in my pool resources (varying lengths between pools, file, job, volume retention all same duration in a given pool). If all file records are purged from a database, the job can still be restored. If all job records on a volume have been purged, the volume will be purged. If all job records on a volume expire before a volume expires, the volume will still be purged. This will because bacula thinks the volume has nothing useful on it. If a volume's retention period expires before the jobs on that volume expire, the volume will still be purged. In the event that you have a volume that contains data but has no catalog entries for jobs or files, and you want to restore data from that volume, you do have options. Among these are: Use bscan to scan the volume and add all contents from the volume to the bacula catalog, so you can then do a restore through bacula. Use bls to review the contents or various details about the volume. Use bextract to extract the contents of the volume to some destination without the assistance of a working bacula environment. Robert Gerber 402-237-8692 r...@craeon.net On Mon, Jun 23, 2025, 11:48 AM Bill Arlofski via Bacula-users < bacula-users@lists.sourceforge.net> wrote: > On 6/23/25 10:11 AM, Stefan G. Weichinger via Bacula-users wrote: > > > > greetings > > > > today a customer asks me for a list of files in a directory at a given > > date in february > > > > I open Bacularis-5.0.0, and want to use "Restore" to browse the database: > > > > there's a job backing up the samba-share containing the relevant > > directories. > > > > What scares me: > > > > I choose a FULL backup but when I come to "Step 3 - select files to > > restore", it tells me: > > > > "It seems that there is no files for choosing or file records in > > database for this job has been purged (file retention period expired)" > > > > So the Job is in the DB but "without content" ? > > > > I assume the files are on tape anyway ... right now the tapes are > > off-site so I can't try ... but I assume I could run some full restore > > and search my files in there? > > > > - > > > > Would the catalog contain that information? > > > > I backup the catalog also even that someone told me here it wouldn't be > > nec > essary anymore ... > > > > I have a catalog backup from early march ... > > > > thanks for any pointers here. > > > > Seems I have to review my setup ... > > Hello Stefan, > > This is not a Bacularis issue, and it is a Bacula issue only in the sense > that Bacula is doing what it has been > told/configured to do. :) > > You will need to review your File, Job, and Volume retention periods to > prevent this in the future. > > What seems to have happened is that Bacula has pruned the File records for > this Job from the catalog, but the Job record > still exists. > > Typically, in (very) large environments we see people setting the file > records to be pruned sooner than the job and volume > records. This is to keep the Bacula catalog DB size under control. The > file table takes up the most space, so people make the > decision to configure File retention periods to be smaller than the Job > retention periods so that they can go back and > restore specific Files for some period of time, and when that passes, > they can still go back and restore the Job(s), but they > know and accept that they will not be able to choose specific files from > the job to restore. > > If it is critical in this case that you are able to choose specific > files/directories to restore, you can take a look at the > job log and identify the volumes it used. Then you can use `bscan` to scan > each of these volumes - in the correct order - and > re-insert the file records back in to the database. There are more things > to consider here, but this is an option. > > You current choice is to just restore the entire job, and then do the > inspection of the files/directories once the restore is > complete. > > I know this is probably not the answer you wanted to hear. :-| > > If your environment is not very large (think million/billions of files), > then typically we recommend to set the File and Job > retention periods to be the same so that if the Job is in the catalog, > then you know that you will be able to select specific > files from > that job. > > > Best regards, > Bill > > -- > Bill Arlofski > w...@protonmail.com > _______________________________________________ > 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
