i have 1 client who have 2 branch office
office 1 backup computer on server 1
office 2 backup computer on server 2
now they want to have the backup data of server 1 on server 2 and backup data of server 2 on server 1
that way if something happen they have off site backup of everything (bandwidth and storage is not an issue)
both server are identical (windows server 2019 with datadedup enable), what’s bothering my is the hardlink and also i don’t want both UrBackup instance to “overgrowth”. like copying over the “new file” over the new file … and we got and infinite loop
Hope im clear (sorry english is not my primary language)
I guess because of different lan you ll run into discovery issues
You can specify an internet servers in urbackup, so the discovery of new clients will works fine (in each server specify the other internet server).
In your case do not specify two internet servers, because urbackup client will only attach to the first one it see. ( @uroni could you allow two internet servers at the same time?)
Then on each server, you ll see all the clients ( local and internet ones).
But you can still enable/disable each client differently on each servers (better use groups for this).
So disable office 2 computers on server 2, and enable then on server 1 and vice versa.
I’d say the issue is solved via server to server replication. I do it with btrfs send and receive, so it is operating system + file system dependant and I see no point to solve it directly in UrBackup. (And I have never done that with Windows Server, so no idea about that)
@orogor If you can describe a use case where the issue is not solved via server to server backup replication, that would make me reconsider the feature priority of “UrBackup client that backs up to two different Internet servers”.
hi @uroni , thanks you for considering that improvement.
For example in his case, he would replicate the whole server and that’s not what he want, he wants :
site A on server B
site B on server A
not
site A and B on server A
site A and B on server B
#=== Space and bandwith gain =================
Plus btrfs replication would need a primary server, if this is server A
site A backup to server A and is then replicated to server B
site B backup to server A and is then replicated to server B
This would double the strain of the uplink of site B, compared of sharing the strain on upload of site A and site B
Data would go B->A->B, so bandwidth is basically wasted.
He would also need twice the amount of storage on both side
#=== Client conf flexibility =================
You can have a situation were you want most clients to backup to two locations … except :
for some very large clients due to them being very large this is not reasonable
or maybe they are not that much important to justify their copy being in two locations
#=== Server conf flexibility ================
If you have two different servers, maybe you want to use different settings and different retention because the drive size isn’t the same.
If you use btrfs send, then it would be highly recommended to have the same disk space.
But maybe you own one server and rent the other one, and you want to backup less often with less retention on the amazon one than in your datacenter.
#=== No need to search for backup ================
With the current way of doing things, if you restart a server a client will attach to the other server.
So backups for one day are in a location or another, so you need to actually search on which server your backup for that day is.
#=== More elegant =================
I think it’s more elegant to add support for two internet servers at the same time (instead of the client switching between the two), then let the user choose to disable backup for a client on a server or another.
If the feature was made to help handle HA on the firewall, then i guess the admin who needs it, is at a sufficient skill level to configure haproxy in tcp mode or something to handle that.
No, I replicate individual backups (btrfs sub-volumes). Not the whole volume. Replicating the whole volume isn’t even possible with btrfs. So no need for a primary server or something.