[Cialug] Landscape of SQL servers

David Champion dchamp1337 at gmail.com
Mon Oct 17 15:03:55 CDT 2016


The point is RAID or replication doesn't protect you the "rm -f" or "drop
table students" situations, the mirrored or replicated locations will just
have the same problems as the master. If you don't have a backup, that data
is gone.

I use RAID and replication and they have saved my bacon many times in the
event of a hardware failure, but they are not backups. I've seen several
businesses in trouble because someone told them they were covered with a
RAID, and they lost a lot of important data that they should have been
backing up.

-dc

On Sun, Oct 16, 2016 at 9:36 AM, Matt <matt at itwannabe.com> wrote:

> There is a very loud (likely majority) in the IT world that will
> constantly repeat to you "RAID is *NOT* a BACKUP."  I've heard it many
> times in LUG meetings.  A backup's purpose is to allow you to recover not
> only from failed equipment (from which RAID does an excellent job of
> protecting you... assuming you pay attention to all your arrays and make
> sure to notice and replace failed drives quickly) but also from computer
> errors (program, virus, OS bugs that can cause data corruption) and human
> errors (oops, I just typed `rm -rf /` because my buddy told me it would
> optimize my intertubes and help connect them to my megapipes!).
>
> In a perfect world, backups should also protect your data from acts of God
> and evil men, plus stuff like faulty wiring and plumbing (your house gets
> struck by lightning, which causes the gasoline, detcord, and C4 that your
> mad scientist neighbor has been stashing in your storage shed while you and
> your family are off on vacation to explode, which causes the house to shake
> so violently that the plumbing for the 2nd story bathroom bursts and pours
> water on your 1st story office computer and your 21U rack in the
> basement).  A good backup system keeps a copy of all important data not
> only nearby for a quick restore when a tiny disaster strikes, but also
> keeps that same data somewhere safely offsite in case a major disaster has
> a much wider area of effect.
>
> All that said, I am a huge fan of RAID.  I had a faulty PSU in my desktop
> machine that was eating a hard drive every couple of months.  It took me a
> while to figure it out, but I never had to reload from backup because I was
> able to replace the failed drive before the next drive would die.  What
> RAID was designed to do was to not only protect your data, but to keep that
> data accessible, even when a failure happens.  It will keep you working
> when a drive fails, and it will give you time to replace it, so it can help
> you avoid one of the major hassles of a backup system: recovering from a
> loss.  It can also make sure that your primary system and your primary
> backup are safer places to store your data.  It just can't mitigate human
> error, data corruption, or natural disasters.
>
> -- Matt Stanton
>
>
>
> On 10/14/2016 9:14 PM, L. V. Lammert wrote:
>
>> On Fri, 14 Oct 2016, Scott Yates wrote:
>>
>> Sorry, but I still think you are wrong.  This article states many of the
>>> reasons I think so:
>>>
>>> https://www.mongodb.com/blog/post/backup-vs-replication-why-
>>> do-you-need-both
>>>
>>> Two problems there - it is specific to the configuration of a specific
>> database (MongoDB), that only describes the tools available in that
>> enviornment.
>>
>> Second problem, it only describes threat solutions for that enviornment.
>>
>> I guess we're both entitled to our opinions.
>>
>>         Lee
>> _______________________________________________
>> Cialug mailing list
>> Cialug at cialug.org
>> http://cialug.org/mailman/listinfo/cialug
>>
>
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>


More information about the Cialug mailing list