On 10/30/2015 2:16 PM, Dimitri Maziuk wrote: > I'm burning in a 7.0.5 (since I don't see 7.2 RPMs in Simone's repo) > server with the latest vchanger and 8 disk "magazines", 3TB each. Here's > what I get backing up a 5+TB filesystem -- note that this is just a > burn-in, not production: > > - full backup runs from 22-Oct 21:05 to 29-Oct 02:36, > - it's done spooling the first volume on Oct 23 01:17 and it writes it > to vchanger_7_9 -- *that is the last volume in the last magazine*, > - and then wakes up and starts writing to mag 0, fills it up, moves over > to mag 1 in sequence. > > This is commodity spinning run disks so I have a post-job script that > rsyncs the last written magazine to another drive (poor man's guard > against drive failure). For that to work, it is very important that a > backup is *not* spread randomly over different magazines. > > Is that even doable with bacula? > > Josh, do you think the ordering could be enforced by vchanger maybe?
No. Volume selection is fairly complex. The order in which volumes are purged greatly affects the next available volume selection. With multiple pools, varied retention times, and occasional error jobs, there is no way to maintain a static order. Most likely you will have to change the post-job script to rsync the particular volumes, rather than a magazine. Alternatively, you could manually move volume files between magazines so that all of the volumes that need to be rsync'd are on one magazine. Vchanger does not care which volumes are on which magazines as long as a update slots command is issued to inform Bacula of the moved volumes. ------------------------------------------------------------------------------ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
