Am 19.06.24 um 09:46 schrieb Radosław Korzeniewski:
Did you label your tapes? You can't use tapes in Bacula without labeling.
Sure I did!
When you label your tapes, just use "barcodes" options and Bacula will
read all barcodes from tapes and label them to match.
Then you should put all your new tapes in the Scratch pool during
labeling, so Bacula can take one to the selected pool when required.
That's new to me. Is it relevant for my current issue?
I want it to use existing volumes, not new ones.
Pool "daily" should not create a "Vol-" volume in the "File" storage ...
it shouldn't use "File" at all.
Finally you should configure the "Recycle" pool parameter pointing to
the Scratch pool, so all your unused tapes will return to it, closing
the cycle.
When carefully configured it will automatically rotate all your tapes,
which is good for them.
I hope it helps
phew, sounds even more complicated to me right now
-> adding Scratch pool
addon: for weekly and monthly the catalog should run to the according
tapes, not to a "daily" tape, right?
The rule of thumb for the tape backups in Bacula is to use as few pools
as possible. Especially for catalog backup which is technically
redundant (unneeded, see below) and you save it for time saving only
during recovery.
If you have a single tape drive then you are limited to a single pool
usage at any given time, and all your jobs which require another pool
will wait. When your backup window is tight then you want to avoid this.
I personally create tape pools based on required retention, i.e. Tape1W
or Tape1M and join all the pools with similar retention time.
Somewhere I read the catalog should (additionally?) be written to File,
that would complicate it even more.
You should save your BSR file offsite in a secure place this will save a
lot of your precious time during recovery.
A file based volumes are easier to handle, a tape based volumes could be
easier to handle for offsite storage.
So, it all depends on your requirements and ability to fulfill them.
*) your volumes archive all data required for future catalog recovery;
this kind of recovery requires volume scan to populate catalog data,
which can take time to complete; so, it is better and faster to save
catalog backup to avoid volume scan.
ok, I think I understand ... but actually I don't see the todo for my
original issue right now.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users