Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Site Related Forums
 Article Discussion
 Article: Introduction to SQL Server 2005 Database Backups

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2007-12-19 : 08:12:15

Backing up a database is one of the most important things you need to do when having a database driven application. It 's only all of your data in there, right? But often developers and management don't realize the importance of backups and overall proper backup strategy for the most important side of the business – data and it's consistency.



Read Introduction to SQL Server 2005 Database Backups

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2007-12-19 : 08:40:03
Looking forward to read next chapter!



E 12°55'05.25"
N 56°04'39.16"
Go to Top of Page

dbird
Starting Member

4 Posts

Posted - 2007-12-19 : 11:23:32
Great article. It reminded me of some backups useful backup options that I forgot about. Definitely worth keeping as a quick reference.

Go to Top of Page

talleyrand
Starting Member

35 Posts

Posted - 2007-12-20 : 10:46:39
Under "Full database Backup", the SQL comment is misleading
-- Back up the AdventureWorks as differential backup

Otherwise, thank you for an informative article


Go to Top of Page

graz
Chief SQLTeam Crack Dealer

4149 Posts

Posted - 2007-12-20 : 11:20:12
Yes it is. So much for my proof reading skills. It's fixed.

=================================================
Creating tomorrow's legacy systems today. One crisis at a time.
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2007-12-20 : 11:28:51
and mine...

_______________________________________________
Causing trouble since 1980
blog: http://weblogs.sqlteam.com/mladenp
SSMS Add-in that does a few things: www.ssmstoolspack.com <- new version out
Go to Top of Page

R
Constraint Violating Yak Guru

328 Posts

Posted - 2008-05-02 : 10:42:24
Hi

Will there be a 'next article' ?

Hopefully yes, there will...!
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-05-04 : 06:48:48
yes there will be. real life sometimes gets in the way of things

_______________________________________________
Causing trouble since 1980
blog: http://weblogs.sqlteam.com/mladenp
SSMS Add-in that does a few things: www.ssmstoolspack.com
Go to Top of Page

web3media
Starting Member

1 Post

Posted - 2008-10-16 : 00:06:11
Yes, very good article. Thank you. Can you answer a question for me, though? Does the FULL recovery apply or help if you haven't run a backup? I need to restore a 2005 db to a recent point in time, but have no backups . Any to take advantage of the info in the transaction logs and get the db back to the desired point in time
Thanks in advance.
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2008-10-16 : 04:05:50
No. If there are no backups at all, then the log will be getting auto-truncated, just as it it were simple recovery. Besides, you always need a to restore a full backup first and then apply log backups.

--
Gail Shaw
SQL Server MVP
Go to Top of Page

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2008-10-16 : 10:30:22
quote:
Originally posted by GilaMonster

No. If there are no backups at all, then the log will be getting auto-truncated, just as it it were simple recovery.

First I've heard of that. It was my understanding that the log file would grow, regardless of whether a backup had ever been taken.
Do you have any references to support that?

If it is not practically useful, then it is practically useless.
Go to Top of Page

GilaMonster
Master Smack Fu Yak Hacker

4507 Posts

Posted - 2008-10-16 : 13:54:59
Yes. A couple, though no one seems to state it clearly.
[url]http://www.sqlskills.com/blogs/paul/post/BACKUP-LOG-WITH-NO_LOG-use-abuse-and-undocumented-trace-flags-to-stop-it.aspx[/url]
quote:
The common use is when the transaction log grows to be inordinately large on a database that's in FULL (or BULK_LOGGED) recovery mode. This happens after a database backup has been taken, which switches the log into a mode where it won't truncate until its been backed up. In these circumstances, if you don't take a transaction log backup, the log will continue to grow until it runs out of disk space.

[url]http://www.sqlskills.com/blogs/paul/post/Search-Engine-QA-1-Running-out-of-transaction-log-space.aspx[/url]
quote:
So what causes the transaction log to fill up in the first place? It could be a number of different things. The two most common ones I've seen are:

* The database is in full recovery mode with normal processing, a full database backup has been taken but no log backups have been taken. This commonly happens when an application goes into production and someone decides to take a backup, without realizing the consequences. Log truncation is not automatic in such a case - a log backup is required to allow the log to truncate.


Books Online: (SQL 2008 BoL)
quote:
A continuous sequence of log backups is called a log chain. A log chain starts with a full backup of the database. Usually, a new log chain is only started when the database is backed up for the first time, or after the recovery model is switched from simple recovery to full or bulk-logged recovery. (topic: Working with Transaction Log Backups )

quote:

If you must switch from the simple recovery model to the full recovery model, we recommend that you:

Immediately after you complete the switch to the full recovery model or bulk-logged recovery model, take a full or differential database backup to start the log chain.

The switch to the full or bulk-logged recovery model takes effect only after the first data backup.


Schedule regular log backups and update your restore plan accordingly.

Log backups are an integral and fundamental aspect of the full and bulk-logged recovery models. Log backups allow the transaction log to be truncated. If you do not back up the log frequently enough, the transaction log can expand until it runs out of disk space.
(Topic: Considerations for Switching from the Simple Recovery Model )



There has to be a full backup to base the logs off. If the database has never ever been backed up, then there is no base for log backups to be restored against. Until a full backup is taken, the DB behaves like it's in simple. The same thing happens if the log chain is broken (backup log.. with truncate/switch to simple and back), until a base for the log chain exists, the log records aren't retained.

It's easy to test. Create a DB, put it in full recovery. Check the log space used. Do a large transaction (insert a few million rows into a table. Check the log space used. Checkpoint. Check the log space again.



--
Gail Shaw
SQL Server MVP
Go to Top of Page

joseph
Starting Member

10 Posts

Posted - 2009-09-18 : 05:35:38
quote:

Tail log backup

There seems to be a lot of confusion about this one since it's a new term in SQL Server 2005 (I haven't heard it being used in SS2k)

As far as I know,the tail log backup were existed in SQL2K.
Go to Top of Page

Alex_Green
Starting Member

3 Posts

Posted - 2012-08-08 : 05:54:20
Very useful article. Thank you so much!

There are a lot of simple third party tools for SQL backup like "SQL Backup and Replication", SQLBackupAndFtp, "Simple SQL Backup", etc. In most standard cases such tools usage is more preferred.
I would to recommend SQLBackupAndFTP which allows you to:
- Save your backups locally, on your LAN or an FTP site.
- Schedule your backups as a Windows task or a Service. In both cases, the tool saves the password for you.
- Differential and Transaction Log backups are also available.
- The tool creates different backup files for each backup, letting you classify them as you wish.
Go to Top of Page

elliswhite
Starting Member

36 Posts

Posted - 2014-05-03 : 01:39:13
I could have take my database backup very smoothly, thanks for sharing article.
Go to Top of Page
   

- Advertisement -