Bacula Copy jobs add the date of the copy as the job date and volume date rather than the date the original file was backed up.
For this example, let's assume the simplest to illustrate. Full backups, one per month, one per volume.
This creates a problem when copying backups to a new location using such a copy job, in that volume retention periods are now wrong. For example, if Backups are configured such that Volume retention is 4 months, Max volumes is 6, and period is 1 month, 6 files will eventually sit on the disk. The file dates are something like:
2022-05-01
2022-06-01
2022-07-01
2022-08-01
2022-09-01
2022-10-01
Then, when the backups are copied, using PoolUncopiedJobs in a recurring Job to keep the second location up to date, initially 6 files will be stored on the second location. Let's say this happens the next day. Now there are 12 volumes in the catalog.
When the copy task is called again on 2022-11-02, it will fail. Why? Because Bacula will look through its Job records and fail to find anything old enough that it will purge, as the six existing records/files are all marked on 2022-10-02, when they should have the timestamps that the original files had (as I don't really care when something got copied, only how old the data actually is). I consider this a bug, as there's no simple way to make bacula manage an offsite backup automatically in a way that doesn't involve manually creating all the files.
One possibility to get around this would be to modify the database, and manually set the file modification times to the correct values for Job completion, Volumes, etc etc. using a batch script that's called each time the Copy Job completes. There's just many date records in there, some in UNIX timestamps, some in sql DATE fields, and I'm not sure which one(s) are used by the program to determine if it can purge volumes; the C code is a bit hard to follow.
What would I need to change in the database to work around the bug?
