<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: February Question: What is one of your best practices for making full backups and transactions log backups of your production databases?</title>
	<atom:link href="http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/</link>
	<description>Brad M. McGehee, Director of DBA Education, Red Gate Software</description>
	<lastBuildDate>Wed, 28 Jul 2010 16:53:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: bradmcgehee</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-3/#comment-376</link>
		<dc:creator>bradmcgehee</dc:creator>
		<pubDate>Fri, 02 Apr 2010 21:51:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-376</guid>
		<description>The February Question of the Month is now closed.</description>
		<content:encoded><![CDATA[<p>The February Question of the Month is now closed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Antony</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-3/#comment-338</link>
		<dc:creator>Antony</dc:creator>
		<pubDate>Mon, 22 Mar 2010 21:21:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-338</guid>
		<description>I&#039;m the only DBA \ Database Developer for a small e-commerce company. When I started, one of the first things i did was construct a new backup strategy - previously they had been doing a full backup once a day, and running their transactions in simple recovery mode.

There are a variety of databases, several of which see little write activity, so are still backed up once per day.
The two main transactional databases are now in full recovery, with transaction log backups every 15 mins.

System databases are also backed up once per day, as are the &quot;Utility&quot; databases I have created (one for administrative procedures/maintenance routines, and one as an area for loading / saving ad-hoc data and for rolling back ad-hoc data changes, etc) - I also backup the system databases whenever I make modifications to jobs, logins etc.

All the backups are written initially to a local hard disk on the same server (tran log backups are also mirrored directly to another server, as are the system databases). A second stage of the backup process then uses 7zip to compress the full backups and copy them to a secondary server.

The live servers are remote from the office in which we work, so the compressed backups are downloaded several times during the week to our office location, restored locally, and depersonalised/sensitive data removed/replaced for distributing to the development team (and for my own use wearing my &quot;database developer&quot; hat). We also periodically restore the transaction logs to verify the backups.

I have another maintenance job that deletes old backup files, and has a configuration for each backup type/location of how long to keep a backup file, and the minimum number of files to retain.

This is all done through a combination of my own stored procedures and an SSIS Package that invokes 7zip and performs the server-copy, all scheduled as jobs in SQL Agent, with notifications to an operator on failure.

So far this is working well. My goal is to automate the movement of the backups from the live site to the office, but that is currently beyond my control.</description>
		<content:encoded><![CDATA[<p>I&#8217;m the only DBA \ Database Developer for a small e-commerce company. When I started, one of the first things i did was construct a new backup strategy &#8211; previously they had been doing a full backup once a day, and running their transactions in simple recovery mode.</p>
<p>There are a variety of databases, several of which see little write activity, so are still backed up once per day.<br />
The two main transactional databases are now in full recovery, with transaction log backups every 15 mins.</p>
<p>System databases are also backed up once per day, as are the &#8220;Utility&#8221; databases I have created (one for administrative procedures/maintenance routines, and one as an area for loading / saving ad-hoc data and for rolling back ad-hoc data changes, etc) &#8211; I also backup the system databases whenever I make modifications to jobs, logins etc.</p>
<p>All the backups are written initially to a local hard disk on the same server (tran log backups are also mirrored directly to another server, as are the system databases). A second stage of the backup process then uses 7zip to compress the full backups and copy them to a secondary server.</p>
<p>The live servers are remote from the office in which we work, so the compressed backups are downloaded several times during the week to our office location, restored locally, and depersonalised/sensitive data removed/replaced for distributing to the development team (and for my own use wearing my &#8220;database developer&#8221; hat). We also periodically restore the transaction logs to verify the backups.</p>
<p>I have another maintenance job that deletes old backup files, and has a configuration for each backup type/location of how long to keep a backup file, and the minimum number of files to retain.</p>
<p>This is all done through a combination of my own stored procedures and an SSIS Package that invokes 7zip and performs the server-copy, all scheduled as jobs in SQL Agent, with notifications to an operator on failure.</p>
<p>So far this is working well. My goal is to automate the movement of the backups from the live site to the office, but that is currently beyond my control.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dallas</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-284</link>
		<dc:creator>Dallas</dc:creator>
		<pubDate>Mon, 08 Mar 2010 23:31:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-284</guid>
		<description>We&#039;re implementing a sql 2008 DB for a client very soon. It&#039;s &lt;1gb db to run on a single server.. but still not bad for my first production effort :)

The plan is to full backup weekly w/ nightly diffs.  The tlog will be 15 minutes.  They get copied off to the network and usb drive, which is taken offsite.  I like the convenience of disk, especially for remote sites with non-IT personell.

I&#039;ll have a vmware guest to run on the production server, which will (hopefully) retain an identical configuration setup to the production machine. test restores etc can be done on the guest.  It shouldn&#039;t run 24/7 lest it interfere with the production.

db scripts are from sqlservercentral.com</description>
		<content:encoded><![CDATA[<p>We&#8217;re implementing a sql 2008 DB for a client very soon. It&#8217;s &lt;1gb db to run on a single server.. but still not bad for my first production effort <img src='http://www.bradmcgehee.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>The plan is to full backup weekly w/ nightly diffs.  The tlog will be 15 minutes.  They get copied off to the network and usb drive, which is taken offsite.  I like the convenience of disk, especially for remote sites with non-IT personell.</p>
<p>I&#039;ll have a vmware guest to run on the production server, which will (hopefully) retain an identical configuration setup to the production machine. test restores etc can be done on the guest.  It shouldn&#039;t run 24/7 lest it interfere with the production.</p>
<p>db scripts are from sqlservercentral.com</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bradmcgehee</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-258</link>
		<dc:creator>bradmcgehee</dc:creator>
		<pubDate>Wed, 03 Mar 2010 06:13:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-258</guid>
		<description>Shawn, I can&#039;t agree with you more, a proactive DBA always has to always be prepared for the worst.</description>
		<content:encoded><![CDATA[<p>Shawn, I can&#8217;t agree with you more, a proactive DBA always has to always be prepared for the worst.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shawn Johnson</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-256</link>
		<dc:creator>Shawn Johnson</dc:creator>
		<pubDate>Wed, 03 Mar 2010 05:25:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-256</guid>
		<description>Brad,

Thanks!   The process that I wrote about above was fully tested as one company that I have helped for more than 20 years had an office in Santiago Chile that was for the most part destroyed in the recent earthquake.  As the quake started, the Business Continuity Plan (BCP) was initiated and the backup and disaster recovery processes that I had helped setup worked.  We only lost about 15 minutes of data (because it happened early in the morning and just around 15 minutes after the last log backup and log shipping).  There were other snafu&#039;s in the BCP from an organizational and communication perspective that we will fix but at least the data was safe.  We have been fortunate that all of our staff has been accounted for and they are being helped getting their life back in order.  

So, I guess the boy scout motto of &quot;Be Prepared&quot; is really worthwhile as you never know when your processes will be put to the test and how important of a test it will be.  

Thanks much!

Shawn</description>
		<content:encoded><![CDATA[<p>Brad,</p>
<p>Thanks!   The process that I wrote about above was fully tested as one company that I have helped for more than 20 years had an office in Santiago Chile that was for the most part destroyed in the recent earthquake.  As the quake started, the Business Continuity Plan (BCP) was initiated and the backup and disaster recovery processes that I had helped setup worked.  We only lost about 15 minutes of data (because it happened early in the morning and just around 15 minutes after the last log backup and log shipping).  There were other snafu&#8217;s in the BCP from an organizational and communication perspective that we will fix but at least the data was safe.  We have been fortunate that all of our staff has been accounted for and they are being helped getting their life back in order.  </p>
<p>So, I guess the boy scout motto of &#8220;Be Prepared&#8221; is really worthwhile as you never know when your processes will be put to the test and how important of a test it will be.  </p>
<p>Thanks much!</p>
<p>Shawn</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bradmcgehee</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-253</link>
		<dc:creator>bradmcgehee</dc:creator>
		<pubDate>Tue, 02 Mar 2010 00:49:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-253</guid>
		<description>The February SQL Aloha Question of the Month is now over, and you can find out the winner here: http://www.bradmcgehee.com/2010/03/winner-of-the-february-sql-aloha-contest/. Thanks for taking the time to enter the February contest, and you can enter the March contest here: http://www.bradmcgehee.com/2010/03/march-question-what-is-the-biggest-mistakeproblem-you-have-ever-found-on-a-sql-server-instance-and-how-did-you-fix-it/.</description>
		<content:encoded><![CDATA[<p>The February SQL Aloha Question of the Month is now over, and you can find out the winner here: <a href="http://www.bradmcgehee.com/2010/03/winner-of-the-february-sql-aloha-contest/" rel="nofollow">http://www.bradmcgehee.com/2010/03/winner-of-the-february-sql-aloha-contest/</a>. Thanks for taking the time to enter the February contest, and you can enter the March contest here: <a href="http://www.bradmcgehee.com/2010/03/march-question-what-is-the-biggest-mistakeproblem-you-have-ever-found-on-a-sql-server-instance-and-how-did-you-fix-it/" rel="nofollow">http://www.bradmcgehee.com/2010/03/march-question-what-is-the-biggest-mistakeproblem-you-have-ever-found-on-a-sql-server-instance-and-how-did-you-fix-it/</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Kinsella</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-245</link>
		<dc:creator>Patrick Kinsella</dc:creator>
		<pubDate>Thu, 25 Feb 2010 19:09:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-245</guid>
		<description>Frequent restoring is one of my best practices for making full backups and transaction log backups of my production database. Business needs require me to always have a copy of my production database with current data. Having this need forces me to do daily restores of my production database to another system. This helps in two ways; one, I validate daily that the backups I&#039;m taking are good and not corrupt or failing. Second, this practice gives me some level of comfort that if the need for a production restore ever occurred, I will be prepared.</description>
		<content:encoded><![CDATA[<p>Frequent restoring is one of my best practices for making full backups and transaction log backups of my production database. Business needs require me to always have a copy of my production database with current data. Having this need forces me to do daily restores of my production database to another system. This helps in two ways; one, I validate daily that the backups I&#8217;m taking are good and not corrupt or failing. Second, this practice gives me some level of comfort that if the need for a production restore ever occurred, I will be prepared.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leo Silva</title>
		<link>http://www.bradmcgehee.com/2010/02/february-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/comment-page-2/#comment-238</link>
		<dc:creator>Leo Silva</dc:creator>
		<pubDate>Wed, 24 Feb 2010 22:05:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.bradmcgehee.com/2010/02/march-question-what-is-one-of-your-best-practices-for-making-full-backups-and-transactions-log-backups-of-your-production-databases/#comment-238</guid>
		<description>I wrote:
&quot;After that, Transaction Log job was scheduled to start after maintenance plan had finished, so we didn’t log any maintenance stuff. In our case, it was possible to do that.&quot;

About transaction log schedule, our issue was a bit more complex. 
We needed to get rid of maintenance stuff log. At that time we had no much space in Prod server. 
So, we save &#039;restore mode&#039; for all dbs in a temp table, change restore mode to simple in the beginning of maintenance plan, and restore to old restore mode in the end of maintenance plan.

Sorry for the inconvinience. I guess it&#039;s not the goal of the question.

Leo</description>
		<content:encoded><![CDATA[<p>I wrote:<br />
&#8220;After that, Transaction Log job was scheduled to start after maintenance plan had finished, so we didn’t log any maintenance stuff. In our case, it was possible to do that.&#8221;</p>
<p>About transaction log schedule, our issue was a bit more complex.<br />
We needed to get rid of maintenance stuff log. At that time we had no much space in Prod server.<br />
So, we save &#8216;restore mode&#8217; for all dbs in a temp table, change restore mode to simple in the beginning of maintenance plan, and restore to old restore mode in the end of maintenance plan.</p>
<p>Sorry for the inconvinience. I guess it&#8217;s not the goal of the question.</p>
<p>Leo</p>
]]></content:encoded>
	</item>
</channel>
</rss>
