Am 23.01.24 um 15:18 schrieb Bill Arlofski via Bacula-users:
Yes, a Copy job will need to read the backup data and by doing so, Bacula will verify the signature (checksum) of each file read. You would be notified in the job of a failure to read back a file with the correct checksum.
Ok, a signature check additionally is good. By the way I though the data from the job simply will be copy without further checking and usingg smartctl before eject to show possible problems registred.
But, as the name implies, you will be copying the data to another storage location, and hence using some additional space - E ven if it is only a temporary scratch space for your copies to be written to.
Thats the reason I want in best to write them to /dev/null and hopefully can use some configuration to do them.
Alternately, you can run a Verify (level=data) job which read the data from the backup media, also verifying the checksum of every file read - without actually writing the data to a second storage location.
Yea, if there is no difference against copy to /dev/null then this is the goal for me.
I have written a script which (just for testing purposes), when calls from a Backup Job's RunScript (RunsWhen = After), automatically restores the entire job but also runs all three Verify levels against the job. You can pick the parts of the script you need (maybe just the Verify level=data), and remove/comment out the rest, or just pick and choose what you need.
I am attaching the script `AutoRestoreAndVerify.sh` which I use in my environment. Please edit the variables at the top and read through the instructions at the top of the script to understand how to implement this script.
Thank you, I will check it carefully what I can use. Pierre _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
