I am pretty sure this isn't possible....
We have a database with several schemas. Each schema belongs to a different user. One user was asking "if I find out I made a whole load of errors would it be possible to revert to the state my data was in yesterday". Obviously we could restore the whole database, but that would restore the other schemas as well which we do not want to do....
You are correct, it is not possible to restore a single schema only.
That said, had you stored all specific schema objects to a specific Filegroup and had been taking Filegroup backups then you could restore just the affected Filegroup.
If you are administering a large number of schemas/filegroups however, this would be quite cumbersome.
Restore the whole database to a database with a different name.
Copy over the parts that you wish to restore.
You have to restore a copy of the whole database to a point in time and then copy over the schema data back into the original database. If this is needed on a regular basis in future you could use filegroups as John suggested and do a partial recovery of a copy, then copy the data back in. But you cannot, even with filegroups, do a partial recovery to a point in time (which is what you're asking for), afaik no such thing exists.
Related
I am looking for a method to view the actual data inside a differential backup file. I have searched on SO and Google but could not find anything useful. Perhaps I am using the wrong keywords.
I have found many articles like this;
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/view-the-contents-of-a-backup-tape-or-file-sql-server?view=sql-server-ver16 and although this has some useful data, it does not let me view the actual data that has been changed since last full backup.
Possible solutions:
Restore a differential backup without the full backup. But I don't see how this is possible.
Use a query or sproc to view the contents of the backup file, much like the summary data is extracted in the example in above link.
Run a query on the running database that will show the data that will be included in the next differential backup
Is any of these possible? If not, are there any other things I can try?
ps. Does not have to be a full view of all data, I could query specific tables if that's the only option.
Using SQL Server 2016
Thanks for any assistance!
Edit. As Martin Smith pointed out in the comments a differential backup on a SQL database differs from a files differential backup, also including rows that have no changes, thus I need to a new strategy.
Basically I need to know all rows that have been changed since a specific time. So I'm thinking about making a full backup and after a specific time, restore this into a new database and then somehow compare both databases by using a query.
I'm using SQL Server 2012 in a local environment. In fact, it is running on my Windows 7 machine. My problem is as follows: I receive a daily backup of my SQL database. Right now, I'm just restoring the whole database on a daily basis by deleting the existing one. This restore task takes quite some time to complete. My understanding of the restore process is that it overwrites the previous database with the new backup.
Is there a way for SQL Server 2012 to just modify the existing database with any changes that have occured in the new backup? I mean, something like comparing the previous database with the updated one and making the necessary changes where needed.
Yes, instead of a full backup you ill need a differential backup. Restore it to move to a "point in time" state of original database.
Make a basic research about full/differential and log backups (too many info for a short answer)
I don't believe so. You can do things with database replication, but that's probably not appropriate.
If you did have something to just pull out changes it might not be faster than a restore anyway. Are you a C# or similar dev? If so, I'd be tempted to write a service which monitored the location of the backup and start the restore programatically when it arrives; might save some time.
If your question is "Can I merge changes from an external DB to my current DB without having to restore the whole DB?" then the answer is "Yes, but not easily." You can set up log shipping, but that's fairly complicated to do automatically. It's also fairly complicated to do manually, but for different reasons: there's no "Microsoft" way to do it. You have to figure out manual log shipping largely on your own.
You could consider copying the tables manually via a Linked Server. If you're only updating a small number of tables this might work just fine, and you could save yourself some trouble. A linked server on your workstation, a few MERGE statements saved to a .sql file, and you could update the important tabled in the DB as you need to.
You can avoid having to run the full backup on the remote server by using differential backups, but it's not particularly pleasant.
My assumption is that currently you're getting a full backup created with the COPY_ONLY option. This allows you to create an out-of-band backup copy that doesn't interfere with existing backups.
To do what you actually want, you'd have to do this: on the server you set up backup to do a full backup on day 1, and then do differential backups on days 2-X. Now, on your local system, you retain the full backup of the DB you created on day 1. You then have all differential backups since day 1. You restore the day 1 full DB, and then restore each subsequent differential in the correct order.
However, differential backups require the backup chain to be intact. You can't use COPY_ONLY with a differential backup. That means if you're also using backup to actually backup the database, you're going to either use these same backups for your data backups, or you'll need to have your data backups using COPY_ONLY, both of which seem philosophically wrong. Your dev database copies shouldn't be driving your prod backup procedures.
So, you can do it, but:
You still have to do a full DB restore.
You have considerably more work to do to restore the DB.
You might break your existing backup procedures of the original DB.
Is there a way to backup certain tables in a SQL Database? I know I can move certain tables into different filegroups and preform a backup on these filegroup. The only issue with this is I believe you need a backup of all the filegroups and transaction logs to restore the database on a different server.
The reason why I need to restore the backup on a different server is these are backups of customers database. For example we may have a remote customer and need to get a copy of they 4GB database. 90% of this space is taken up by two tables, we don’t need these tables as they only store images. Currently we have to take a copy of the database and upload it to a FTP site…With larger databases this can take a lot of the time and we need to reduce the database size.
The other way I can think of doing this would be to take a full backup of the DB and restore it on the clients SQL server. Then connect to the new temp DB and drop the two tables. Once this is done we could take a backup of the DB. The only issue with this solution is that it could use a lot of system restores at the time of running the query so its less than ideal.
So my idea was to use two filegroups. The primary filegroup would host all of the tables except the two tables which would be in the second filegroup. Then when we need a copy of the database we just take a backup of the primary filegroup.
I have done some testing but have been unable to get it working. Any suggestions? Thanks
Basically your approach using 2 filegroups seems reasonable.
I suppose you're working with SQL Server on both ends, but you should clarify for each which whether that is truly the case as well as which editions (enterprise, standard, express etc.), and which releases 2000, 2005, 2008, (2012 ? ).
Table backup in SQL Server is here a dead horse that still gets a good whippin' now and again. Basically, that's not a feature in the built-in backup feature-set. As you rightly point out, the partial backup feature can be used as a workaround. Also, if you just want to transfer a snapshot from a subset of tables to another server, using ftp you might try working with the bcp utility as suggested by one of the answers in the above linked post, or the export/import data wizards. To round out the list of table backup solutions and workarounds for SQL Server, there is this (and possibly other ? ) third party software that claims to allow individual recovery of table objects, but unfortunately doesn't seem to offer individual object backup, "Object Level Recovery Native" by Red Gate". (I have no affiliation or experience using this particular tool).
As per your more specific concern about restore from partial database backups :
I believe you need a backup of all the filegroups and transaction logs
to restore the database on a different server
1) You might have some difficulties your first time trying to get it to work, but you can perform restores from partial backups as far back as SQL Server 2000, (as a reference see here
2) From 2005 and onward you have the option of partially restoring today, and if you need to you can later restore the remainder of your database. You don't need to include all filegroups-you always include the primary filegroup and if your database is simple recovery mode you need to add all read-write filegroups.
3) You need to apply log backups only if your db is in bulk or full recovery mode and you are restoring changes to a readonly filegroup that since last restore has become read-write. Since you are expecting changes to these tables you will likely not be concerned about read only filegroups, and so not concerned about shipping and applying log backups
You might also investigate some time whether any of the other SQL Server features, merge replication, or those mentioned above (bcp, import/export wizards) might provide a solution that is more simple or more adequately meets your needs.
I'm looking for a simple (simplest if possible) way of backing up and restoring a database.
I want to do a backup in one state and then after doing some operations get back to the backed up state.
Tried Database->Tasks->Back Up... and then Database->Tasks->Restore but I always get an error with:
Restore failed for...DBName
The tail of the log for the database "database name" has not been backed up...
So, I want to back up and restore with one simple operation each, can one advise me
to a solution, be it GUI or not GUI based?
Use the WITH REPLACE option of the RESTORE command:
The REPLACE option overrides several
important safety checks that restore
normally performs. The overridden
checks are as follows:
Restoring over an existing database with a backup taken of another
database. With the REPLACE option,
restore allows you to overwrite an
existing database with whatever
database is in the backup set, even if
the specified database name differs
from the database name recorded in the
backup set. This can result in
accidentally overwriting a database by
a different database.
Restoring over a database using the full or bulk-logged recovery model
where a tail-log backup has not been
taken and the STOPAT option is not
used. With the REPLACE option, you
can lose committed work, because the
log written most recently has not been
backed up.
Overwriting existing files. For example, a mistake could allow
overwriting files of the wrong type,
such as .xls files, or that are being
used by another database that is not
online. Arbitrary data loss is
possible if existing files are
overwritten, although the restored
database is complete.
The topic is also covered at nauseam in MSDN see Restoring Without Using a Tail-Log Backup, which contains the links for 'How to' articles that cover Management Studio scenarios (ie. the tool you're using).
It looks like you have Differential Backups set up. It is slightly more complicated than restoring a Full backup.
http://msdn.microsoft.com/en-us/library/ms175510.aspx
By doing a Full backup, you are going to break the chain of backups that the DBA set up, so it would be a good idea to check first with the DBA before you break his backup set.
Edited for very helpful comments:
You should use the COPY_ONLY option when you do a backup so that you do not break the chain of backups.
http://msdn.microsoft.com/en-us/library/ms186865.aspx
When restoring you need to check the option to Overwrite existing database, if you are, otherwise it will fail.
MSSQL 2005 and up features snapshots, sounds like it suits your requirements nicely.
I'm using SQL 2005. I can right click on a database and create scripts for the database that will recreate the structure (tables, views, stored procedures) elsewhere. Or just as a backup, version, etc.
But, is there a way I can schedule it to do this? And output to a folder I choose?
I really appreciate the help.
Don
You could schedule this using SMO probably, though it may take some work to get up and running.
However, a more elegant approach might be to schedule a full backup to a new file (with today's timestamp), and archive it. This way retrieving the scripts is as simple as restoring that version of the database somewhere, and extracting manually.
An even better approach: if you store your change scripts in source control, you should always be able to pull any version of the database.
I've used both SMO's predecessor (SQL-DMO) from VB as well as ApexSQLScript from the command line to do scheduled scripting of objects.
This is fine for very large databases where you do not have ability to quickly restore a database just to look at schema versioning information for small tables/views/procs which happen to live in the same database.
In fact, this is a good argument for separating out small fast-changing schemas into separate databases from large-slowly changing schemas.