<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Famous Last Words</title>
	<link>http://www.nicksimonsen.com/2007/05/01/famous-last-words/</link>
	<description>When in doubt, blog it out!</description>
	<pubDate>Wed, 08 Feb 2012 07:41:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2</generator>

	<item>
		<title>By: Geoff</title>
		<link>http://www.nicksimonsen.com/2007/05/01/famous-last-words/#comment-35</link>
		<author>Geoff</author>
		<pubDate>Tue, 01 May 2007 18:06:17 +0000</pubDate>
		<guid>http://www.nicksimonsen.com/2007/05/01/famous-last-words/#comment-35</guid>
		<description>Just to add more to Nick's story: He came prepared with a solution, and needed only assurance that he wasn't going to make things worse. As he already had a (thankfully recent) copy on his computer, recovering from the problem wasn't a big deal. But it could have been a lot worse. 

You'll find as you move into larger projects that relying on a code management system (such as CVS, Subversion, Starteam, Visual Source Safe, etc.) won't always save your bacon. There are times when doing a full-on backup is a wise idea. 

Things to consider: 

1) How much are you potentially changing? A few files or a whole website? 

2) Are you working with a database? (You might want to back up the DB, too, to ensure less of an impact.)

3) Are you modifying server configuration? 

Remember that Wiki update we did? We backed up EVERYTHING. For the very reason of the upgrade not working properly. We restored a few times until we got it right. Imagine what would have happened if we hadn't backed up first...</description>
		<content:encoded><![CDATA[<p>Just to add more to Nick&#8217;s story: He came prepared with a solution, and needed only assurance that he wasn&#8217;t going to make things worse. As he already had a (thankfully recent) copy on his computer, recovering from the problem wasn&#8217;t a big deal. But it could have been a lot worse. </p>
<p>You&#8217;ll find as you move into larger projects that relying on a code management system (such as CVS, Subversion, Starteam, Visual Source Safe, etc.) won&#8217;t always save your bacon. There are times when doing a full-on backup is a wise idea. </p>
<p>Things to consider: </p>
<p>1) How much are you potentially changing? A few files or a whole website? </p>
<p>2) Are you working with a database? (You might want to back up the DB, too, to ensure less of an impact.)</p>
<p>3) Are you modifying server configuration? </p>
<p>Remember that Wiki update we did? We backed up EVERYTHING. For the very reason of the upgrade not working properly. We restored a few times until we got it right. Imagine what would have happened if we hadn&#8217;t backed up first&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter M.</title>
		<link>http://www.nicksimonsen.com/2007/05/01/famous-last-words/#comment-34</link>
		<author>Peter M.</author>
		<pubDate>Tue, 01 May 2007 17:41:35 +0000</pubDate>
		<guid>http://www.nicksimonsen.com/2007/05/01/famous-last-words/#comment-34</guid>
		<description>Nice job on the recovery. I've been there before myself and had over written another worker's files. Now I'm preaching the gospel of "backup" wherever I go. It's nice to know that everybody can make an honest mistake. The important thing is how you went about correcting your mistake.</description>
		<content:encoded><![CDATA[<p>Nice job on the recovery. I&#8217;ve been there before myself and had over written another worker&#8217;s files. Now I&#8217;m preaching the gospel of &#8220;backup&#8221; wherever I go. It&#8217;s nice to know that everybody can make an honest mistake. The important thing is how you went about correcting your mistake.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

