Home > Backup, Uncategorized > Real-world example of snaps vs. backup

Real-world example of snaps vs. backup

Following up from my last post comparing snapshots with replication to backup, one of my peers sent me the following info:

“You may have heard about the issues Google experienced with Gmail a while ago.  Data Loss.  No problem because they replicate all data to a second data center, right?   But sometimes you’re replicating bad data or a software bug, which is what Google seems to be saying here.  But they back up their data. ” 

http://gmailblog.blogspot.com/2011/02/gmail-back-soon-for-everyone.html

Pretty interesting stuff here, particularly that Gmail is backed up (kudos to Google).    It also raises a very real use-case where snapshots or data on disk doesn’t have to be corrupted, rather the OS of the system storing the snapshots could have a bug that renders the snapshots invalid. 

Typically, storage arrays that are replicating require that both sides be running the same code level.  Usually when doing an upgrade, you upgrade the remote site first, then upgrade the source side.   Running both sides at different code versions for an extended period of time isn’t an option as it causes an issue getting support from the manufacturer, but some code bugs related to the upgrade may not pop up for 30, 60, or even 90 days.

Advertisements
Categories: Backup, Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: