I'm trying to come up with a backup strategy for SQL Server 2005. I am thinking of doing full backup once a week, differential backup once a day and transaction log backup every 15 minutes. The database is around 50gb in size. The thing is that the database is live every second of the day. Will the full backup disturb any operations? Do I need to do anything in particular to make backups go smooth without pausing any database operations?
SQL Server live database backup strategies
backupsql-server-2005
Related Solutions
Some interesting suggestions here, which all seem to show misunderstanding about how log backups work. A log backup contains ALL transaction log generated since the previous log backup, regardless of what full or differential backups are taken in the interim. Stopping log backups or moving to daily full backups will have no effect on the log backup sizes. The only thing that affects the transaction log is a log backup, once the log backup chain has started.
The only exception to this rule is if the log backup chain has been broken (e.g. by going to the SIMPLE recovery model, reverting from a database snapshot, truncating the log using BACKUP LOG WITH NO_LOG/TRUNCATE_ONLY), in which case the first log backup will contain all the transaction log since the last full backup - which restarts the log backup chain; or if the log backup chain hasn't been started - when you switch into FULL for the first time, you operate in a kind of pseudo-SIMPLE recovery model until the first full backup is taken.
To answer your original question, without going into the SIMPLE recovery model, you're going to have to suck up backing up all the transaction log. Depending on the actions you're taking, you could take more frequent log backups to reduce their size, or do more targeted database.
If you can post some info about the maintenance ops you're doing, I can help you optimize them. Are you, by any chance, doing index rebuilds followed by a shrink database to reclaim the space used by the index rebuilds?
If you have no other activity in the database while the maintenance is occuring, you could do the following:
- make sure user activity is stopped
- take a final log backup (this allows you to recover right up to the point of maintenance starting)
- switch to the SIMPLE recovery model
- perform maintenance - the log will truncate on each checkpoint
- switch to the FULL recovery model and take a full backup
- continue as normal
Hope this helps - looking forward to more info.
Thanks
[Edit: after all the discussion about whether a full backup can alter the size of a subsequent log backup (it can't) I put together a comprehensive blog post with background material and a script that proves it. Check it out at https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]
Well, if you aren't saving the logs, the best you can do is roll back to your last diff.
What I generally do is backup the transaction log on much shorter intervals (maybe every 15 minutes or so). This prevents me from losing a lot of data in the worst-case scenario (the machine burns to the ground). This is a very lightweight operation, so this can be done online with minimal impact.
You should generally only use Full backup mode, and you should back up your transaction log often, unless you can afford to lose up to a full day's worth of data, which is what you're exposed to now.
Best Answer
Backups work perfectly. No interruption of the database. What you will see is higher IO load, obviously, as the backup io performance comes up on top of the disc IO.
In addition, memory requirements are higher than without backups - obviously.