up vote 0 down vote favorite
share [g+] share [fb]

As a system admin, backup is a necessary job. But how hard could it be in backing up a website, such as StackOverflow?

All your need is to backup the dlls, htmls, js, php, web.config, .htaccess and what-have-you, and then you generate SQL scripts for your database schema and your data in plain text. And then you store all those texts on a remote site, that's it.

Similarly, restore should be easy. And if anything goes wrong ( such as the SQL scripts get corrupted), you can still manually correct it.

Am I right?

I am asking whether my backup strategies are making sense or not, so there is definitely a question

link|improve this question
54% accept rate
2  
That say it isn't the backup which is the problem -- but the restore :) – Keiran Holloway Dec 17 '09 at 9:33
2  
I see someone's been reading the blog... – womble Dec 17 '09 at 9:34
Database replication helps a lot. Using that technique you have a synced database on several servers. Dumping the database to SQL can be done with small databases, but it would definetely kill an SQL server when restoring a database that huge (refering to stackoverflow) – halfdan Dec 17 '09 at 9:34
Do you actually have a question? – John Gardeniers Dec 17 '09 at 11:55
I am asking whether my backup strategies are making sense or not, so there is definitely a question. – Graviton Dec 17 '09 at 13:39
show 1 more comment
feedback

2 Answers

up vote 1 down vote accepted

As womble's already said, yes and no.

Case in point: we have several basic (to be kind about it) e-commerce sites, all created by hammering the square peg that is WordPress into the round hole of our business requirements. We grab a copy of the contents of /srv/www and /etc, plus a dump of the MySQL DB and all's well and good (and yes, I have run a test restore!)

On the other hand, our main site runs on six servers (3 web, 2 DB and one publisher/load-balancer). All we need for backup purposes, though, is the website code/files (all in SVN, backed up from our dev server) and a dump from one of the DB servers (they're both identical; replication partners, to give us some redundancy).

Neither of these methods is any righter than the other, I'm just making the point that you should only backup what you need to; the backup footprint for the main site is about 4GB, while backing up all the servers involved would take us up to several hundred GB. We can also restore faster by deploying new servers and sticking the data/files back on them than we could by restoring six servers worth of data.

link|improve this answer
feedback
up vote 3 down vote

Am I right?

Yes... and no. Sure, making a copy of every piece of data involved in the site is all that's required. But what are all those pieces? How do you know you have them all? How do you ensure that you keep the list of what's required up to date, given that the site is constantly changing over time?

As Keiran hinted at in the question comments, testing the restore is the only way to be sure, and the cost (in extra hardware and software licences), hassle (it takes a quite a while to do a restore) and the natural optimism of IT people[1] conspire together to make restoration testing a very, very low priority.

[1] I firmly believe that anyone who isn't an optimist at heart would blow the back of their head off after working in this industry for about 15 minutes.

link|improve this answer
1  
Yes, you have to do scheduled restores on a spare server to ensure your backups are fine. – Maxwell Dec 17 '09 at 9:45
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.