The need for a unique Syncronsation, Update and Backup in Persistence Frameworks

Long time ago I've head the idea of combining the synchronization issues, backups and the update process together. Our application for travel agency accounting is based on a SQL Server and installed in hundreds of travel agencies in Germany. About one third uses SQL replications to synchronize data with their branch offices or for telework.

Now we need solutions for the following problems:

• The sql servers connected via replications must be updated together
• Software upgrades requires downtime of the application
  
• Restoring an old backup of the data requires an upgrade of the SQL database
  
• Crash of the consolidated database requires a complete regeneration of the replication from one of the remote databases
• Crash of the remote database requires generating a new database from the consolidated database
• And so on...

With the new system we want:

• Upgrade our product with no downtime
• Upgrade branch offices and teleworkers step by step with no downtime
• Restore backups of old versions with automatic upgrade
• Restore a backup in a branch office and synchronize it to the head office
• synchronize between branch offices if the head office becomes unavailable (peer sync)

This could only be reached, if we put the upgrade and synchronization layer in the business logic. This is the goal for the synchronization, backup and upgrade framework on top of the famous DataObject.NET 4.0 from x-tensive.