On 23.01.2022 11:37, Radosław Korzeniewski wrote:
Hello,
pt., 21 sty 2022 o 14:22 Peter Milesson via Bacula-users
<bacula-users@lists.sourceforge.net> napisał(a):
If somebody has got experience with disk based, multi volume Bacula
backup, I would be grateful about some information (tips, what to
expect, pitfalls, etc.).
The best IMVHO (but not the only mine) is to configure one job = one
volume. You will get no real benefit to limit the size of a single
volume.
In the single volume = single job configuration you can set up job
retention very easily as purging a volume will purge a single job only.
It is not required to "wait" a particular volume to fill up to start
retention. Purging a volume affects a single job only. And finally you
end up with a way less number of volumes then when limiting its size to
i.e. 10G.
There are many different approaches which can fit different
requirements.
I don't see the benefit of having a single job per volume as Bacula
is tracking media, files, jobs and everything else.
That's why Bacula has a catalog which allows the backup system
to determine the location and state of volumes, jobs, files, etc.
To logically separate backup data I use pools and leave the rest
to Bacula.
When Bacula needs a particular file volume, if it's available Bacula
will simply use it and if it's not or if we are using tape volume
which is currently not in the tape drive/library, Bacula will ask
for the volume by name.
The number of smaller file volumes (e.g. 10GB) is not an issue as
Bacula is handling them correctly and automatically (provided that
Bacula is correctly configured, of course).
I'll go through few examples where smaller file volumes (e.g. 10GB)
could prove useful:
1. If the catalog database get corrupted or completely lost,
due to the the small size, it's easier and faster to handle
and determine volumes which contain database backup.
That makes the process of importing the data into a new
catalog database using a tool such as bscan easier.
2. Similar to 1), it is easier to manage small file volumes and
extract particular jobs from a volume using bextract tool.
3. If the space is an issue (as it usually is), bigger volumes
tend to eat more space which cannot be reused (volume
cannot be recycled) as long as the volume contains a single
job we want to preserve.
4. Although I don't like that approach, sometimes people chose
to sync or copy whole file volumes to a secondary location
using the usual tools such as rsync, cp and similar.
In such case it is better to keep file volumes small.
5. When recycling a file volume, it will take longer time to
wipe bigger file volume. If a volume is smaller it will
take less time to recycle ensuring more time windows where
other tasks could benefit from I/O performance. In case of
large file volumes all other tasks would have to fight for
the opportunity to access the file system and that gets more
obvious when a slow network file system is being used.
6. In case of any kind of corruption of a file volume due to
the file system corruption or damage in transport, it is
likely that less data will be lost in case of a smaller
file volume. And again, it's easier to handle smaller file
volume when trying to recover pieces of data.
Regards!
--
Josip Deanovic
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
