Re: Way of working or dangerous?

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