<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Good info. Much I didn't know and a bit I was misguided on. Thank you Jon! <br><br>--- On <b>Tue, 10/13/09, Jon Thompson <i><jon@mac-consultant.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Jon Thompson <jon@mac-consultant.com><br>Subject: [DM-MUG] Backups (in response to the Danger/Sidekick Fiasco)<br>To: "Des Moines Mac Users Group" <dmmug@dmmug.org><br>Date: Tuesday, October 13, 2009, 1:06 PM<br><br><div id="yiv844327904">Victoria alluded to this in another post, but it requires some further explanation...<div><br></div><div>The fiasco with the Sidekick phones is apparently a result of poor planning on the part of Microsoft, and their SAN integrator- Hitachi. </div><div>(As a side note, I am a SAN admin, so I deal with these technologies on a day to
day basis.)</div><div><br></div><div>Apparently Hitachi was updating the Storage Area Network (SAN,) which went south. Microsoft then went to their backup of the data, which was also corrupt. Updating a SAN is a relatively risky procedure, often requiring zero corruption on many tens of Terabytes of data. Because of this nature, it is imperative that a good backup is performed, as a heavily corrupt SAN is usually unrecoverable (a single file can be spread between not only many hard drives, but many devices.)</div><div><br></div><div>This provides the opportunity to talk about backups a bit...</div><div><br></div><div><b>1) A good backup is a verifiable backup</b></div><div><br></div><div>If you are dumping info into Time Machine, and you are _never_ pulling info back out of it and checking, how do you know that the data is good? In the instance of the SideKick data, this means that they would have known that the backup is good, and that they could rely
on it. Until you know that you can recover from it, you cannot call it a good backup.</div><div><br></div><div><b>2) A good backup consists of many backups of the same data.</b></div><div><br></div><div>I store three months of backups, and I consider that too little, but don't dare increase my budget. If you are relying on all of your data being on a single hard drive, what happens if there is a fire and both your computer and backup is lost? If all of your backup is in one cloud (Mozy) and that cloud bursts like the SideKick cloud did, you are hosed. Now, if you have daily backups on a time machine volume, and a weekly backup to Mozy, you are protected from either example. Mozy is your offsite backup, the time machine </div><div><br></div><div><b>3) Synchronization is not backup.</b></div><div><br></div><div>Synchronization ensures that all of you data is the same between all instances that you create. If you are syncing your address book on your
mac with an iPhone, you have two instances of the data, but they are tied together. If you delete a contact on one (or a virus deletes all of them) that deletion is transferred to your backup. I realize that there are ways that the sync service tries to reduce the chance of this, but it is still a possibility. However, an offline copy of your address book on a USB thumb drive that is not plugged into your computer cannot not be changed, at least until it is plugged in again. Dropbox is a synchronization service.</div><div><br></div><div>Part of the Sidekick debacle is because it is apparently a synchronization service. They are telling people not to power down their phones, because it apparently wipes the internal memory and re-downloads content from Microsoft servers. Of course there isn't any data to re-download...</div><div><br></div><div><b>4) RAID is not backup.</b></div><div><br></div><div>RAID (except 0) is a way to protect from hard drive
crashes. It does not protect from application corruption, accidental deletion, or intentional deletion. All of which are much more likely than hard drive corruption during the majority of the life of a hard drive. RAID is useful for server admins that deal with distributing data amongst many hard drives, which actually is a great way to exponentially </div><div>increase the likelihood of data loss due to hard drive failure.</div><div><br></div><div>RAID 0 offers no protection at all- in fact, it is will exponentially increase your likelihood of data loss due to hard drive failure. Be careful when purchasing large external hard drive, as they are sometimes two drives that are internally configured as RAID 0. This is useful for professional video primarily.</div><div><br></div><div><b>5) Backup as sparse as you are willing to recover from.</b></div><div><br></div><div>- If you couldn't stand losing more than a week's worth of data, you'd best be
backing up weekly.</div><div></div><div>- If you couldn't stand losing more than a day's worth of data, you'd best be backing up daily.</div><div></div><div>- If you couldn't stand losing more than an hour's worth of data, you'd best be backing up hourly. </div><div><div><br></div><div>You know what is important and what is not. Make sure to taylor your backup routine to your needs. Incremental backups, such as Time Machine are good about this.</div><div><br></div><div><b>6) Recovery options are available, but expensive.</b></div><div><br></div><div>Data recovery costs a minimum of $1000 for a hard drive. And they don't guarantee they can recover anything.</div></div><div><br>
-- </div><div>- Jon</div></div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>DMMUG mailing list<br>Use this Address to send mail to the list:<br><a ymailto="mailto:DMMUG@dmmug.org" href="/mc/compose?to=DMMUG@dmmug.org">DMMUG@dmmug.org</a><br>Use this page to modify subscription options:<br><a href="http://cialug.org/mailman/listinfo/dmmug" target="_blank">http://cialug.org/mailman/listinfo/dmmug</a></div></blockquote></td></tr></table><br>