Marco, In my last email, I couldn't think of many good ways to extend the retention of jobs and files after they had run.
However, I have an idea. If you have some pool like 'Archive pool' and you set in that pool File, Job, and Volume retention to some very long period, like 1000Y, then if you migrate jobs you want to archive to that pool, *I think the migrated jobs should inherit the new pool's retention period.* I believe it should work, because pool retention periods override retention periods from all other sources, and jobs migrated to a pool should certainly inherit the settings from that new pool. *You would have to test to confirm this does work as expected.* One way to test this behavior would be to do the opposite of what you want to do. Create a pool named 'migration-test-very-short-retention'. Set File, Job, and Volume retention to some low value, like 1D. Create a test job with unimportant data, using one of your normal pools and a small test fileset. Run that job, creating a small, yet unimportant normal backup. Make a note of the jobid, and migrate that jobid to the new migration test pool. Wait a day. Does the jobid disappear from the list of jobs? When selecting jobs for migration, keep in mind that it is very important you include all the relevant dependent jobs. In other words, you will not have a good result if you only migrate the incremental backups for a job, and not the full / diff backups those incrementals depend on. Of course, you must also watch out for problems like this when setting volume status to archive, so this problem is not unique to migration. There are necessary steps to setting up a migration job that I have not included here. Let me know if you need more information on migration / copy jobs. Regards, Robert Gerber 402-237-8692 r...@craeon.net On Sun, Jun 1, 2025 at 2:37 PM Rob Gerber <r...@craeon.net> wrote: > Marco, > > In this email I will reference information from the bacula 15.x manual. > See link below. > > https://www.bacula.org/15.0.x-manuals/en/main/Automatic_Volume_Recycling.html > > From the 15.x manual, PDF section 31.2, Pruning Directives: > AutoPrune = <yes∣no> If AutoPrune is set to yes (default), Bacula will > automatically apply the > Volume retention period when running a Job and it needs a new Volume but > no appendable > volumes are available. At that point, Bacula will prune all Volumes that > can be pruned (i.e. > AutoPrune set) in an attempt to find a usable volume. If during the > autoprune, all files > are pruned from the Volume, it will be marked with VolStatus Purged. The > default is yes. > Note, that although the File and Job records may be pruned from the > catalog, a Volume > will be marked Purged (and hence ready for recycling) if the Volume status > is Append, Full, > Used, or Error. *If the Volume has another status, such as Archive,* > Read-Only, Disabled, > Busy, or Cleaning, *the Volume status will not be changed to Purged.* > > [snip] > > Once a job has been pruned, you can still restore it from the backup > Volume, provided that the Volume has not been recycled, but one additional > step is required: > scanning the volume with bscan. > [snip] > > *I take this to mean that the volumes with status 'archive', all > associated jobs and file records will still be pruned from the catalog if > they are past their retention period, but the volume won't be reused. What > was your experience when actually working with a volume with status > 'archive'?* > > I think that one way to 'lock' retention for certain media is to set the > volume and associated job retention (and maybe file retention) to some > large value (like 1000Y). Please note that if you set volume retention to a > very long period but jobs all expire, the volume will still be recycled > (unless you set 'recycle = no' on the volume). I think manually setting job > and file retention to a greater period than originally used for many jobs > on a given volume could be complicated and difficult. *I am not sure it > is possible to extend the retention of a job / file record after the job > has ran.* I think there are easier ways, but not ones that preserve your > catalog entries for jobs and file records past their configured retention > periods. > > You could also set recycle = no on the volumes in question after the > volume is labeled. This would not allow recycling, but I think this is > almost the same as setting volume status 'archive' since a Volume must be > marked as 'recycled' or 'purged' in order to be recycled. > > You could set 'recycle = no' on all your pools, but you would need to > manually recycle expired volumes. This change would probably not apply to > previously labeled volumes unless you updated the volumes in > bconsole. Probably not what you want unless you're absolutely certain this > is preferred for you. > > Please keep in mind that if you make changes to pools or jobs in the > configuration, these changes will not be applied to jobs that already ran, > or volumes there were already labeled / used (maybe moving a volume from > one pool to another might 'refresh' the settings on the volume to apply the > settings from the new pool). The manual says you can update a volume's > settings from pool settings using 'update volume from pool' (I haven't > tested this). > > Default file, job, and volume retention periods are specified in the > bacula code. A file / job retention period can be specified in the client > resource, and these override the defaults. File, job, and volume retention > periods can be specified in the pool resource, and these override retention > specified anywhere else. File records are not necessary to restore a job > from a volume, but the entire job must be restored if you are missing the > file records. A volume with no more jobs will be recycled even if the > volume retention has not expired unless auto-prune or recycle are set to > 'no'. > > *In short, I think volume status = archive should have kept the target > volume from being recycled, but wouldn't have preserved any job or file > records that passed their retention period. *If you need to restore from > a volume in such a state, I recommend you add its contents to the bacula > catalog using the bscan tool. You could also examine its contents using > 'bls /path/to/volume' (to see all contents) or 'bls -j /path/to/volume' (to > see just job listings). You should also be able to manually extract the > data in the volume without bacula's assistance using bextract. > > > Regards, > Robert Gerber > 402-237-8692 > r...@craeon.net > > > On Fri, May 2, 2025 at 6:11 AM Marco Gaiarin <g...@lilliput.linux.it> > wrote: > >> >> There's some way to 'lock' metadata/catalog retention for a media? >> >> I supposed that put a media in 'Archive' state (before catalog retention >> expire) suffices, but seems not... >> >> >> Thanks. >> >> -- >> >> >> >> >> _______________________________________________ >> 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
