We have customers who, for unassailable reasons, cannot use SQL Server’s built-in backup features because it backs up the entire database. These customers need to breakup and backup the database into subsets of who owns the data so the appropriate parties can backup their own data according to their own rules. My question is two-fold:
- How would I do something like this?
- Have you ever been asked to partition your backups like this? If not, have you ever been asked to do something that appears to fly in the face of the industry standard? People in our company suggest we/I should simply ‘roll our own’ backup process that backs-up just the required subsets of data. This means, of course, that we/I should simply ‘roll our own’ restore process. When I argue that this is the definition of reinventing the wheel and part of why we chose SQL Server in the first place, I get the sense that they think I am being a tech snob and/or lazy.
I suspect their opinions are based on experience with another product that was Access-based and stored each logical unit in a separate database that could simply be copied.
Update: I finally got around to implementing this by backing up the ‘complete’ database using SMO, restoring the backup, and deleting records from the backup that are not part of the subset. I am quite disappointed to find this resulted in the transaction log growing to upwards of 5GB within a 5 minute period. It seems like creating an empty database and inserting will be easier, but how can I replicate the schema without having a static script that needs to be updated as the database is updated?
I can see why one would like to do it this way, its an easy way to open up the DB for a advanced customer and letting the customer only work and mess around with its own data. They can use that to create own reports with direct access to the datasource and do whatever they want with it.
I would call that ‘Export’ and ‘Import’ of data, not a ‘backup’. But its playing with words. We do that kind of exports a lot in some of our systems.
On the ‘How to’ I have to have more information, do they want it exported to another server, same sever but another database, or something else?
It could be done by jobs running at night or by a service pushing the data. Other tools exists for this too. Maybe using DTE-packages running at night or triggered. Or having a program made that fetch the data when requested.
Edit: Answer the comment:
In the most of the cases we drop existing subsetdb and then restore an empty db and fill it with the filtered data. Another way is to just backup full, restore as new database and delete the rows that is not part of subset.
I presume that the subsetdb is more of a ‘read-only’-db with statistical data, so you dont have to worry writeing over changes and so on.