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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users