Checklista: backup av en rails-applikation

Jag tänkte försöka sätta ihop en checklista som kan vara bra att ha när man ska göra backup av sin rails-applikation. Tanken är att kunna återställa den så snabbt och smärtfritt som möjligt på en ny server om den gamla skulle försvinna av en eller annan anledning.

Visst har oftast webbhotellen backup, men det är ändå alltid bra att ha en egen. Jag har råkat ut för webbhotell (Proinet) där servern har kraschat och ingen backup finns att tillgå. Hur ofta du behöver köra backup är ju helt beroende på hur viktig data du har. En gång per dygn brukar vara en bra lösning, de flesta applikationer har råd att förlora det senaste dygnets körningar. Driver du en bank lär du vilja köra backup oftare än så. :)

Koden för applikationen

Jag jobbar mot ett subversion-repository, så den senaste källkoden finns alltid där. Subversion är egentligen ingen backup, men eftersom repositoryt och applikationerna ligger på helt skilda servrar finns alltid den senaste versionen av applikationen på minst två ställen. För att få riktig sinnesro bör man nog även köra backup på hela sitt subversion-repository.
Ta en titt på SVNbackup om du behöver automatisera det hela med ett script.

Databasen

De flesta av våra applikationer körs mot någon form av databas, vanligtvis MySQL eller SQLite. När det gäller SQLite är det enkelt, bara att kopiera över databasfilen. MySQL använder jag mig av mysqldump för att få en kopia av databasen.
Sitepoint har en kort guide för hur man använder mysqldump.

Delade filer

Mina applikationer brukar ofta lagra filer som användarna laddar upp i shared-mappen. Dessa behöver också backas upp på något sätt. Så fort det handlar om backup av vanliga filer brukar jag använda mig av rsync eftersom du slipper överföra varenda fil på nytt. Jag har gjort en liten genomgång över hur rsync fungerar.

Dokumentation

Du vet säkert hur man sätter igång din applikation, men vad händer om du blir sjuk eller drabbas av plötslig minnesförlust. En tydlig dokumentation är oftast lösningen på problemet. Det folk brukar glömma är att skriva en tydlig beskrivning av hur man sätter igång applikationen. Är det något speciellt med just din applikation som man behöver tänka på? Behöver man några extra bibliotek eller rubygems? RMagick? Skriv ner det i dokumentationen. Den bör finnas med i subversion, och den har du ju redan backup på.

Automatisera!

Dina backuper ska köras automatiskt. Du är en människa, vilket innebär att du kommer att glömma göra backup någon gång. Den gången du glömmer det kommer naturligtvis hela servern att krascha. Crontab är ett bra verktyg för att automatisera saker. Det ingår i de flesta linux-distributioner vilket även inkluderar Mac OS X.

Backup och drift ska inte vara på samma plats

Det verkar inte vara självklart för alla att man ska placera backup och drift på två olika platser. En brand som sabbar din produktionsserver kommer ju också att förstöra din backup om de står på samma fysiska plats, eller ännu värre på samma maskin. Det behöver inte vara så avancerat, sätt upp en enkel filserver i en garderob på kontoret/hemma eller köp in billig lagring från Amazon S3 exempelvis.

Testa att det fungerar

Skriv in i din kalender att prova dina backuper åtminstone en gång om året. Ta en slumpvis utvald applikation och se om allt finns med i backupen. Jag hade en applikation som jag trodde att jag körde backup på regelbundet, men det visade sig att jag kopierade utvecklingsdatabasen istället för produktionsdatabasen.

John Nunemaker har fler tips beträffande backup av Rails-applikationer.