Re: Way of working or dangerous?

Hello Arno,

also a good point to mention - the media type.

In fact, it is the same on all storage devices, which currently are no 
autochangers.
I needed to hurry up in getting all the machines backed up since it's 
not possible (from package manager) to have Bareos and Bacula installed 
the same time (on the same machine). So retained all my config, catalog 
and volumes, just uninstalled the software and prepared for rolling back 
in case I need those backups.

So I had to pray for a few days that nothing bad happens, since the 
backup was stopped for a few days, uninstalling Bareos and putting 
Bacula in change. I didn't get enough sleep. ;)

The first thing I noticed in using autochangers was, that Baculum 
preferred the normal storages instead of the autochangers.
But I cannot be sure, whether this was my fault or something weird in 
configuration. After having all the machines safe, I will slowly start 
to reconfigure some things to come back to a more preferrable way 
instead of simply using normal storages.

Best regards,

Jan

------------------------------------------------------------------------
Logo JSIIT Consulting 	JSIIT Consulting 	Phone: 	+49 40 22865465 	
Jan Sielemann 	Telefax: 	+49 40 22865468 	
Riekbornweg 22 	Mobile: 	+49 1578 6769143 	
22547 Hamburg 	GPG-Public-Key: 	809774813E4461D7 
<https://jsiit.net/public/338622A442F25A5869C8ADE9809774813E4461D7.pub.asc> 
	

	: 	
	

------------------------------------------------------------------------
On 1/21/26 00:21, Arno Lehmann via Bacula-users wrote:
> 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
>