Backup Strategy for MSSQL

Hi everyone. As the company's "DBA" (long story) I wanted to get some opinions on my backup plan. Currently, I have the following in place:

Full weekly backup of master.
msdb is treated as a user database, so msdb and two user databases receive Full weekly backups, Daily differentials and hourly transaction log backups.

The maintenence plan will remove logs older than 2 weeks.

Our networking group backs up the MSSQL to tape regularly.

I'm fairly new to DBA work, but if this scenario sounds like a sound plan, I'd appreciate any feedback. Thanks in advance!We back our stuff up nightly, however you have to decide how much info you are willing to lose should your system crash. If weekly backups have been working and you feel confident in your hardware then stick to that schedule.

HTH,
Aric|||

Quote:

Originally Posted by DbAFtW

Hi everyone. As the company's "DBA" (long story) I wanted to get some opinions on my backup plan. Currently, I have the following in place:

Full weekly backup of master.
msdb is treated as a user database, so msdb and two user databases receive Full weekly backups, Daily differentials and hourly transaction log backups.

The maintenence plan will remove logs older than 2 weeks.

Our networking group backs up the MSSQL to tape regularly.

I'm fairly new to DBA work, but if this scenario sounds like a sound plan, I'd appreciate any feedback. Thanks in advance!

Hi there,

Backup / recovery plan should be designed based on the importance of your data. As a consultant i am managing 17 database servers, some servers are configured to run backup routine every hour, whereas, some servers are configured to run backup routine every day. Good luck & Take care.|||Thanks folks for the replies.
Well, the vendors that put the web server and the MSSQL DB in place were using a Simple Recovery Model and I felt the nature of the data dictated transaction log backups. The system accepts college applications and I felt any data loss was something I wanted to avoid due to the importance of that data! The intention is that we can experience minimal loss utilizing the strategy to restore from the weekly full, nightly differential and every half hour transaction log backups.|||</bumpitybump>sql

Backup routines

Hi there,

I am looking for some advice and opinions on daily backup routines on SQL2000 and SQL2005, I want to know what peoples best practices are for nightly full backups. Currently I have the following in place,

job: daily backup

step1. truncate log
step2. shrink log
step3. backup
step. updateusage

job weekly admin

step1. defrag indexes (sometimes re-index + update stats)
step2. truncate log
step3. shrink db
step4. checkdb

Does this look good enough?
is there anything else I should add?
What do you have in place currently?

Thanks for your help in advanceYou should do log dumps more frequently to improve recoverability in case of system failure.
I backup my databases nightly, and do hourly log dumps througout the day. All backups and logs are dumped to disk, and then copied to a network location to guarantee recoverability.|||and you ideally want to move a set of backups offsite and preferably not in the same town\city\suburban sprawl office park just in case of things like hurricanes\flooding\tornados.

another hint. you do not want to truncate your logs. you want to back them up.|||I am lazy and manage a number of different servers. My priorities are to have a consistent backup strategy from server to server and to ensure that the backup will always be there when I need it.

For SQL 2000:
I create two maintenance plans (skipping optimizations, shrinkage and integrity checks).
One maintenance plan is for all the system databases. I do a full backup on these nightly.
One maintenance plan is for all user databases. I do a full backup on these nightly and a transaction log backup hourly (in test, only every three hours).

Depending on the size of the backup, I will backup over the network (we are running 1 GB switched) or local to a dedicated dump disk. Generally, if the aggregate of user databases to be backed up is over 25 GB, then I will back it up locally (we use a SAN, I have a separate job that makes an image copy of the backup disk and runs it to tape once per week).

I set the retention policy to a value based on business requirements and available storage.

For SQL 2005:
I create two maintenance plans.
One does a full backup on all databases (user and system). This runs nightly.
The other maintenance plan does a transaction log backup every hour (three hours in test).
I then edit the maintenance plan to add the retention policy and cleanup activity logs and reports.

All that being said, when you design your backup policy, you need to understand:

1. How much data is your business willing to lose (all, some or none)?
2. How much time is your business willing to spend recovering the database (days, weeks, hours, minutes or seconds)?
3. How much money is your business willing to spend on backup and recovery?

These are the principle drivers for your backup strategy. The technology just lets you achieve the requirements that your business sets for you.

Once you have developed your backup strategy be SURE that you test it. Practice recovery at LEAST every three months. Practice different types of recovery (new build, recover to point in time, recover a full backup, etc).

Remember too, that there are other things that you need to backup on your database server besides just the databases:
1. Linked Server settings
2. DTS Packages
3. Logins
4. Jobs

Regards,

hmscott|||You should do log dumps more frequently to improve recoverability in case of system failure.
I backup my databases nightly, and do hourly log dumps througout the day. All backups and logs are dumped to disk, and then copied to a network location to guarantee recoverability.

If the DB is going to keep growing to a certain size, I would not shrink it, just for it to get to that size again, it's a wasted effort, plus you have to allocate all those extents again, and that's overhead.

I usually do

Full (user and system) - nightly with dbcc checkdb catalog, logins, dts jobs, backup devices, etc.
Differential - 3X a day
TLog - Every 1/2 to 1 hr
nightly idx defrag dbcc indexdefrag.
weekly reindex. dbcc reindex.

backup files not deleting

Hello:
I have a few ideas about what to do on this. But, I still would like to
solicit some opinions, if you don't mind.
We have a SQL Server 2000 client who has a maintenance plan that conducts a
backup of its databases. And, each database is using the Full Recovery Mode
l.
The backup of the databases itself is working perfectly. But, the backup
files (bak files) are not being removed. You see, the maintenance plan
specifies that backup files are to be removed every 2 days. That's not
happening?
Why would that be? I mean, why would part of the maintenance plan (the
backing up of the databases) work but another part of the plan (the removal
of the database files) not work?
Thanks!
childofthe1980sHere is a very good overview as to why this may not work some times fro Bill
at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Thanks
Hari
"childofthe1980s" wrote:

> Hello:
> I have a few ideas about what to do on this. But, I still would like to
> solicit some opinions, if you don't mind.
> We have a SQL Server 2000 client who has a maintenance plan that conducts
a
> backup of its databases. And, each database is using the Full Recovery Mo
del.
> The backup of the databases itself is working perfectly. But, the backup
> files (bak files) are not being removed. You see, the maintenance plan
> specifies that backup files are to be removed every 2 days. That's not
> happening?
> Why would that be? I mean, why would part of the maintenance plan (the
> backing up of the databases) work but another part of the plan (the remova
l
> of the database files) not work?
> Thanks!
> childofthe1980s

backup files not deleting

Hello:
I have a few ideas about what to do on this. But, I still would like to
solicit some opinions, if you don't mind.
We have a SQL Server 2000 client who has a maintenance plan that conducts a
backup of its databases. And, each database is using the Full Recovery Model.
The backup of the databases itself is working perfectly. But, the backup
files (bak files) are not being removed. You see, the maintenance plan
specifies that backup files are to be removed every 2 days. That's not
happening?
Why would that be? I mean, why would part of the maintenance plan (the
backing up of the databases) work but another part of the plan (the removal
of the database files) not work?
Thanks!
childofthe1980sHere is a very good overview as to why this may not work some times fro Bill
at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Thanks
Hari
"childofthe1980s" wrote:
> Hello:
> I have a few ideas about what to do on this. But, I still would like to
> solicit some opinions, if you don't mind.
> We have a SQL Server 2000 client who has a maintenance plan that conducts a
> backup of its databases. And, each database is using the Full Recovery Model.
> The backup of the databases itself is working perfectly. But, the backup
> files (bak files) are not being removed. You see, the maintenance plan
> specifies that backup files are to be removed every 2 days. That's not
> happening?
> Why would that be? I mean, why would part of the maintenance plan (the
> backing up of the databases) work but another part of the plan (the removal
> of the database files) not work?
> Thanks!
> childofthe1980s