Let's say I have a very large database. Its backup starts at midnight and finishes at 02:00 am.
When I recover that backup am I gonna have the state of the database at midnight or 02:00 (or something else)?
Going one step further, let's say that I have multiple databases which contain references to each other's elements. If I backup all databases in parallel starting at the same time, when I recover all of them am I going to have the state of all databases at the same point in time?
The backup process in SQL Server backs up the data files and portions of the transaction log, so it'll be the state of the database at 2am.
You can only guarantee consistency of committed transactions across databases if the backup stops at exactly the same time. This is probably not something you want to rely on, so I'd recommend using frequent transaction log backups in addition to whatever nightly full strategy you're using.
Related
I'm periodically getting backups of an SQL database which I would like to restore in my machine. I'm able to do that with RESTORE fullDB WITH NORECOVERY; RESTORE differentialDB WITH RECOVERY;
However, I need to access the restored database in between, as the interval in which I'm getting the backups can be a few hours.
I tried restoring full backup WITH RECOVERY, but in that case I'm getting exception while restoring differential backup.
NB: It's not just one differential backup, it's real time backups taken every few hours. I'm using C# for executing the operations.
Any help is appreciated to solve the issue. Also, let me know if I'm barking at the wrong tree.
Instead of sending SQL database backups from client as .bak files, should I opt any other way to send the data?
Take a look at the STANDBY option for the RESTORE statement. From the docs:
Specifies a standby file that allows the recovery effects to be undone.
NB - differential backups are based on the last full backup taken. So let's say that you take full backups on Sunday, differential backups every other day of the week and you're restoring every day.
Sunday, you'd restore only the full backup, bringing it online for read by specifying STANDBY with the restore
Monday through Saturday, you'd restore the latest differential backup on top of what you've already restored, again using STANDBY
When Sunday rolls around again, you'd need to restore the new full backup.
That said, you mentioned that you're on SQL Express. The database size limit is 10 Gb. At that size, how long does the restore of the full backup take? Is it worth your time? And even there, it's really "how much time are you saving the robot?" because you've already (presumably) automated the restore.
my tool is deleting data from a table and it takes a lot of time 1/2 days,
meanwhile there are scheduled backups,
can sql server handle this situation or is better to stop the tool?
I can't try the tool because i don't have enough time
SQL Server backups are online, so there is no need to stop your processes during a backup.
However the backup must contain the log records for transactions that occur during the backup, so that the database can be recovered to a consistent state when restoring the backup.
So if your delete process runs in one big transaction, the backup can't complete until it has captured all the log records up to the point when you commit or rollback the long running transaction. So to avoid large backup files and long-running backups, you may want to not take backups while it's running.
But if it commits a series of smaller transactions, it should be fine to take backups while it's running.
I have been building an application to Backup SQL Databases using VDI using SMO.
I have a doubt whether i should be capturing the last backup time of a database along with the LSN or simply, just capture the LSN.
More precisely, i wanted to take Last Backup Time to know that if end-user is using another software to backup their SQL DB's using Copy-only method since copy-only method doesn't update LSN or truncate anything but does update the Last backup time.
So, if i am ignoring the last backup time information of any DB and simply capturing the LSN, is it going to cause any problems for me? in terms of recovery/backup if there are other 3rd party softwares into play?
:::: Edit :::::
I am a backup application developer and i would like to know, should i be capturing the Last Backup time of the database that my end-user would like to backup ? or just simply capture the LSN to maintain the Log chain?
If you're writing your backup software for the purposes of ensuring recoverability (that is you're not taking copy-only backups yourself), don't worry about any copy-only backups that have been taken by others. As you've said, copy-only backups don't affect the backup chain.
The only thing that would mess you up is if someone else is taking a non-copy-only backup interleaved with yours. In that case, you could get into a situation where one of their backups relies on one of yours (or vice versa) and the restore scenario is complicated at a point where it really shouldn't be (i.e. the database is down and you need to recover it).
I am working with a data warehouse with SQL Server 2012 and was wondering what would be the most optimized, automated procedure for a backup/restore strategy.
Current observations and limitations:
1) Cannot use transaction logs as it would affect my load performance - datasets are potentially huge with large transactions
2) Current plan is to do full backup every week and differential backup every day
I am not sure when DML operations will happen as it depends on my application's usage, but is there a way to just track the NUMBER of changes to a database that would trigger a differential backup? A way that would not affect performance? I do not want to be taking unnecessary differential backups.
Would Change tracking be a good solution for my scenario? Or would there be overhead involved? I do not need to know the actual data that was changed, just the fact that it was changed by a certain amount.
Thanks in advance!
Well, there's this ( http://www.sqlskills.com/blogs/paul/new-script-how-much-of-the-database-has-changed-since-the-last-full-backup/ ). I'm just trying to figure out what problem you're trying to solve. That is, if you find that the size is below some threshold, it will be (by definition) cheap to do.
It all depends on your DWH configuration.
1. Is your DWH database partitioned? If yes, It would be easier to do the daily db backup(diff backup) for the current partition ONLY. It's much more smaller set of data to be backed up.
If not, Current plan is to do full backup every week and differential backup every day is the only way since you cannot use transaction log file.
You could also try 3rd party disk (block) level backup software (i.e. Doubletake)....
Hope it helps.
You seem to have a mistaken notion of what a differential backup is. Don't worry; it's common.
When you say things like "track the number of changes to a database that would trigger a differential backup", it implies that you think that a differential backup gets all of the changes since the latest full or differential.
However, a differential backup gets all of the data that has changed since the last full backup only. So, you'd expect the size of subsequent differential backups to get larger and larger. For example, let's say you take a full backup on Sunday and a differential backup every other day. You'd get something like:
Monday: All of the data changed since Sunday's backup.
Tuesday: All of the data changed since Sunday's backup (including Monday's data)
Wednesday: All of the data changed since Sunday's backup (including Tuesday's data)
etc
Additionally, you'd only ever restore at most one differential backup if/when you need to restore your database. For instance, if your database crashed on right before Thursday's backup, you'd restore your last full backup (from Sunday in my example), then Wednesday's differential, and you're done.
As for when to schedule it, that's typically dictated by the rhythm of your business. For instance, you might decide to take a backup just before you kick off your ETL or just after. Doing it during doesn't make much sense as you'd have an inconsistent (with respect to your ETL process) database if you ever need to restore it.
I have a SQL Server 2005 database that is backed up nightly. There backup consists of:
FULL backup of the database.
backup of the transaction log.
These are currently two separate jobs.
The log is huge and I'd like to set things up so that:
the database is backed up in full nightly
the log is set such that I can recover the database from any point between one backup and the next.
How can I set this up so that the log files are manageable? I suspect that the log has never been shrunk, as the log is huge.
You are currently implementing the FULL Recovery Model from the sound of things. This will allow you to restore to a point in time provided that you have a transaction log backup that covers the desired point in time (post full backup).
In order to reduce the size of your required transaction log file, you should look to increase the frequency of your transaction log backups. I would suggest hourly. Once you have gauged the actual usage of your log file, you can then look to shrink it to a more suitable size. The key point to note here is that once a transaction log backup has been completed, the inactive portion of the log file becomes available for use once again. The reason why a transaction log file grows continuously is if the transaction log backups are either, not being taken at all or their frequency is not sufficient.
I would also suggest that you consider performing a mix of DIFFERENTIAL and FULL Backups in order to reduce the collective size of your backed up data. An example schedule would be a weekly FULL Backup, say every Sunday, with daily DIFFERENTIAL backups.
I hope what I have detailed makes sense. Please feel free to contact me directly and I will happily assist you in deploying an appropriate backup strategy for your environment.
Essential References:
How to stop the transaction log
file from growing enexpectedly
Backup and Restoring Databases in
SQL Server
One of the things I find with backups is that people typically don't run them frequently enough - especially when it comes to log file backups. And it sounds like you're correct, that the log file isn't being truncated regularly (which means you're likely wasting premium disk space [1]). More importantly though, that's leaving you completely exposed from a recoverability standpoint.)
Happily though, getting things up and running as you need them isn't so hard. In fact, I'd recommend the following three videos as they should give you the background info you need, and then the step-by-step instructions you'll want to follow to get everything working correctly:
http://www.sqlservervideos.com/video/logging-essentials
http://www.sqlservervideos.com/video/sql2528-log-files
http://www.sqlservervideos.com/video/sqlbackup-best-practices
1 Maximize Storage Performance: http://www.sqlmag.com/Article/ArticleID/100893/sql_server_100893.html
What you are doing is effectively a SIMPLE mode backup with bonus disadvantage of not shrinking the log. There is no point to back up both at the same time. If you're doing a full backup, you can just truncate the log.
If you're going to be able to restore to any point of time, you will have to do a full backup once a day (say) and back up the log few times during the day. See http://msdn.microsoft.com/en-us/library/ms191429(SQL.90).aspx