Seeding s3 Storage

[NorthGuard]

I have 2 MinIO setups - both are currently local, though one will be taken offsite after it is seeded.

I have setup a Backup Copy job ( triggered off the main backup jobs ) to populate the second storage device and that is all set. When I move that second device offsite, it will have a new IP address... so I will need to add it as a new backup repository.

once I do that and change the existing backup copy jobs to point to the newly-added repo ( which is really just the already-populated second repo with a new IP ), will I be able to "Map Backup" so it picks up where it last synced?

If not, what is the proper way to seed S3 backups with immutability?

[Mildur]

Hi NorthGuard

If you use FQDN to connect your MinIO appliance to Veeam, changing IP addresses won't be neccessary
May I ask, why FQDN is no option?
Mapping backup copy chains to a copy job is possible for object storage repositories.

Best,
Fabian

[NorthGuard]

In hindsight, I probable should have used FQDN but didn't think of it. And given the size of backups, I don't really want to wipe and start over again.

So I should be fine to map the backup copy job to the newly-added repo?

[Mildur]

Yes. You will be fine. Backup Chains will be continued.

Best,
Fabian

[NorthGuard]

If I change it to FQDN, would just the veeam server needs to be able to see that FQDN? None of the devices being backed up need to know about it, do they?

[Mildur]

Depends on your configuration which system needs to resolve the FQDN. Devices being backed up don't need to have access to the backup copy repository while the copy job runs.

- With connection mode "direct", all backup repositories with the primary jobs will write copy data directly to the bucket. Those repositories must be able to resolve the FQDN
- With connection mode "over a gateway server", the configured gateway server will copy the data to the bucket. Those gateway servers must be able to resolve the FQDN
- Backup server needs to be able to resolve the FQDN

Best,
Fabian