Data in a Microsoft cluster

I am backing up folders on a drive that is hosted by a Windows cluster and that fails over between two nodes.

I have the UrBackup Client Service for Backups failing over with the disks. i.e. the service only runs on one of the nodes at a time. They connect to the server and all is good. I have scores of successful backups, but…

The initial incremental backup after a failover resembles a full backup – i.e. takes a very long time. (Failovers are rare and because of this issue I strive to not do scheduled failovers for maintenance!)

I’m guessing that is because the C:\Program Files\UrBackup\urbackup folder is out of date on the non-active machine.

Is this the key to the state of the UrBackup client’s backups/hashes/history/…/? Is it “client” specific?

Can I move this folder onto the drive that fails over, but not in a folder that is backed up, and hard link or symlink it to C:\Program Files\UrBackup\urbackup? If so, which (hard link vs symlink)?

If not, is there a different path to glory? Perhaps periodically copy \activenode\c$\Program Files\UrBackup\urbackup to a central location and restore it to the “new” activenode as part of failover?

Or just regularly robocopy it to the inactive node? Then it would minimize how out-of-date it is?

Seems messy.

No help from anyone? Point me to the relevant doc’s if I’m asking too simple of a question?

I think you’re on the right track. A restorable snapshot of the database in UrBackupServer\urbackup is copied (by default) to <backupdir>\urbackup daily. Copying these files to the standby node should help keep them sufficiently in sync. I would prefer copying these instead of the live database because the active node may be backing up or performing cleanup at any time, whereas the static snapshot is done when the database is effectively idle.

Restoring these files is the preferred method for recovering an existing UrBackup Server with its backups and settings after a system crash or machine rebuild.

Have not tested this in a cluster or shared storage application, so no guarantees.

Thanks for the response Don, however, it confuses me.

The cluster is the client, not the server. i.e. The snapshots are of a cluster hosted disk not on a cluster hosted disk.

Are you saying I should be copying something from the UrBackup server to the client?

This seems to be a client thing to me.

@uroni can you give any guidance here?

Sorry, misread that as if you had the UrBackup Server in a failover configuration. As you have found, the Client also has a database of the current status of its directories being backed up so it can offer only changed files to the Server during the incremental file backups.

If the UrBackup Server perceives the two nodes as different computers then rebuilding the file database on both ends can take significant time after a failover event. In that case I don’t think there is a Client-only solution, because the Server database for the newly-activated node will be out of date as well. The Server will see the two nodes as having two separate copies of identical file data, rather than sharing one copy, and so need to update the reference counts for the deduplicated file data on the Server.

Only if the two nodes share a single identity, as seen by the Server, would periodic updates of the standby computer reduce the time needed to re-synchronize all the various tables in use.