Hi Timo,
As you said, the Autochangers/Devices definitions on the initial
bacula-sd.conf file are suggestions on how to use a virtual disk
autochanger with Bacula.
There is a lot of ways to work with disk volumes others that using disk
autochangers, yes.
It will mostly depend on your environment, needs, expectations of what you
want/need.
Could you please explain us better this "disks will be located in
physically different locations"?
I mean, do you want to have all your backups spreaded in all these disks?
Yes, you can use individual storage devices for individual disk devices
defined on your Storage Daemon side.
However, you can take advantage of disk autochangers if you're going to
back your 5 servers in one of your disks:
1) have one autochanger with 5 drives (all your 5 drives pointing to the
same disk volume directory, for example, /backup/volumes)
2) have each device configured with Maximum Concurrent Jobs = 1
3) have your 5 backup jobs running concurrently, each one will use one of
the 5 drives
4) you can have one pool for each server, so you would have all your
backups from one specific server in one specific pool (this could help you
with management)
5) but you can also have all your servers backups running concurrently into
one specific device/volume. In both cases (one drive/volume per job or your
5 jobs using one device/volume) will increase your backup speed.
If your idea is to spread all your backups into all your disks in different
locations (of course if you have enough space for that), you can use
copy/Virtual Full jobs to accomplish that.
Hope this helps.
Best regards,
Ana
On Sat, Oct 1, 2016 at 10:37 PM, Timo Neuvonen <timo-n...@tee-en.net> wrote:
> After using Bacula for close to a decade with a tape autochanger, I'm
> slightly lost with ideas related to disk-based backup I'm now trying to
> implement.
>
> Now I have a fersh test install of Bacula 7.0.5, on CentOS 7. Bacula comes
> from EPEL repo.
>
>
> The supplied example conf files define a "virtual autochanger", that refers
> to two "storage devices" that both actually write to same directory (/tmp
> in
> the example).
>
> While wondering the need for this arrangement, I've figured out that this
> may be to help simultaneous backup/restore jobs run smoothly. However, in
> my
> relatively small environment it makes things look complicated if I define
> every storage this way.
>
> Is the suggested way of using a virtual autochanger a must to make things
> work at all, or is it a way how to avoid problems in a big environment
> where
> may be a lot of simultaneous backup and restore jobs? I have about 5
> servers
> to back up, I'll have the backups running in the nighttime, probably not
> concurrently at all. If and when there will be a need for a restore job, it
> will be a single restore run in the daytime. So no more than a single job
> at
> a time.
>
> Will there be any problem in this case, if I try to simplify the conf files
> and drop away the "autochanger" and one of the two "storage devices" it
> refers to, and just had a single "storage device" per each media type?
>
>
> (My goal is to use 2-3 media types, all disks, but disks will be located in
> physically different locations to increase fire/vandalism safety, besides
> disk faults. Since every media type will require a separate storage
> definition, the number of virtual autochanger definitions would multiply
> correspondingly...)
>
>
> Regards,
>
> Timo
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
