Hi Jan,
Am 20.01.2026 um 18:14 schrieb Jan Sielemann via Bacula-users:
Due to bad internet-connection I need to first store full backups in
Pool-Full, which points to a local sd.
Meanwhile making incremental backups to Pool-Incremental on the remote
sd, I copy the files manually to remote-server.
Since they arrived, I do a checksum-comparison and the update the media
table like so
UPDATE media SET storageid=16 WHERE volumename='Volume-Full-0166';
Besides the hint that rsync might be a useful tool to simplify the
actual volume transfer, I can state that your approach to make the
volumes remotely available would work, as far as I'm aware.
There is one caveat.
There always is, isn't it? :-)
You need to ensure you have storage devices with matching media types on
both SDs, which in itself would be something to only do with great care.
In your particular case, this would work because you actually expect to
move volumes, and you explicitly mark the moved volumes to appear to
"belong" to the correct storage device.
However, Bacula itself does not have the concept of a volume belonging
to a particular device. Once you have a situation where all the "normal"
storage devices are in use and you start a restore which would need one
of the moved volumes, Bacula will notice that it's "normal" storage
device is currently not available, and any other devices using the same
media type will be eligible. End result: You'll either have to copy back
your volumes, or abort the restore, wait, and retry.
In your particular situation, I would set up the local and the remote
storages with distinct media types, and then make sure to update not
only the storageid field, but also update the media type.
Identical media types with different storage daemons is something you
should only do if the devices are expected to share volumes; as Bacula
does not do strict locking of volumes between SDs, you would then still
have a "preferred" storage device (and SD), but could count on the other
one being available if needed. Personally, I'd usually set up things so
that the secondary, emergency side is configured with read-only devices,
and copying / syncinc of volumes is monitored, so that at least I know
when I can end up with inconsistencies and resulting restore errors when
using the secondary site.
Well, and we also have storage groups, where you can actually set up
Bacula in a way that you don't have to manage storage ids manually
(which are supposed to be a behind-the-scenes piece of metadata for good
reasons as far as I understand) but that might actually cause more
trouble for your particular setup :-)
Also note that fixing volume metadata when changing media types or
moving volumes can easily become a nightmare once you start creating
inconsistencies due to configuration changes and partial updates...
thus, in your case, if you find your process to work predictably, don't
touch it -- but be aware that Bacula will eventually fall back to
selecting devices by looking at Media Type settings.
Cheers,
Arno
to the same pool but with a remote storage (where they are physically
present).
It's clear, that the backup only is valid when all the Full-Backup-Files
arrived at the remote location.
Comments welcome!
------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
