Server-backup till Amazon S3

Frisim.com har tidigare haft en kopia av sig som kört på en VPS. Denna VPS har också använts som backup-utrymme. Till denna VPS har jag kunnat köra rsync för att kopiera över filer och databas-dumpar av sådant som ändrats.

Då jag istället börjat använda Amazon EC2 som VPS, och då jag inte tänkt att ha den igång ”alltid”, så har jag flyttat min backup från min VPS till Amazon S3. Det sorgliga är att det inte går att köra rsync direkt mot S3. Därför har jag nu bytt till att göra backup med Jets3t. Jets3t är i första hand ett ”toolkit” för att använda Amazon S3, men innehåller bland annat ett färdigt script för att göra backup, synchronize.sh. Synchronize-scriptet är enkelt att använda, och i princip så tar det argument i form av UP eller DOWN, namnet på din ”hink” (bucket) på S3 och namnet på en lokal katalog. Filer eller kataloger som du inte vill ha med i backuppen utesluts genom att lägga en .jets3t-ignore-fil i respektive katalog. Smidigt i och med att du inte behöver ändra i backup-scriptet när du skapar nya kataloger.

Jag har bara gjort den första körningen, den där alla data kopieras, och en test-uppderating, men jag kan konstatera att det tar rätt mycket tid. Nu har jag inte så mycket data som uppdateras mellan varje backup, men data som måste laddas upp måste naturligtvis föras över till S3 och det verkar gå i en hastighet av c:a 100KB/s. Då har jag valt att lagra på en ”hink” i USA, inte i Europa. Uppladdningshastigheten är inte det segsaste, även om det tar mest tid, utan det är att synchronize.sh inte håller ordning på vad som den tagit backup på lokalt, utan behöver titta hos S3 för varje fil innan den kan avgöra om filen modifierats och behöver uppdateras eller inte. Det blir lite segt, och tar säkert runt 30 minuter för de c:a 30.000 filer som jag vill ha backup på.

Nu är det mestadels programkod och MySQL-data som är intressant att backa upp, så det är inte så kritiskt att det går fort eller görs ofta, så därför verkar Jets3t-backup-scriptet till Amazon S3 vara ett rimligt upplägg för mig. Då mina data inte är stort mer än 1GB så kostar det nästan inget att lagra på S3, och när den initiala uppladdningen är gjord blir det heller inte några höga trafikkostnader. Så länge det handlar om bara c:a 30.000 test av fildatum så kostar det c:a 25 öre, vilket blir minimikostnaden för en backup.

För den som har lite data och vill ha ett backup-system som är enkelt att konfigurera så rekommenderar jag Jets3t. Det är enkelt att använda för såväl server som office-dator. Java kanske känns omständligt på en server, och det kan det vara om du inte redan installerat det och använder det till annat, men samtidigt så har jag noterat att om man kör Centos 4, vilket jag gör, så får man ofta problem med ”för gamla” versioner av t.ex. Ruby eller Python för att köra backup-system såsom Backup-manager eller s3sync och då var Java ett väldigt bra alternativ.

Ett annat alternativ är Quillen. Quillen är ett ”extra lager” till Jets3t, och bör kunna vara något lite snabbare. Senare versioner av Quillen (efter 0.19) använder även Amazon SimpleDB för att lagra backup-information.

Updatering: Efter att ha provat igenom Jets3t så har jag noterat ett problem. Om du har filer med ”dåliga” filnamn, så kommer tyvärr Jets3t att ”krasha” och inte vilja uppdatera din backup. Problemet beror på att Jets3t använder en XML-parser för att kommunicera med Amazon S3, och när S3 skickar filnamn som innehåller tecken som inte är tillåtna i XML så avslutar Jets3t tyvärr backup-processen. Jag råkade ut för detta för filer som jag skapar med ett ”dåligt” PHP script som endera inte raderar radbrytningar i slutet på strängar/filnamn, eller också ersätter å, ä och ö med tecken som inte är ”XML-kompatibla”. Detta S3-problem är tydligen välkänt. Detta är troligen inte ett problem som är vanligt för ”normalanvändaren”. I övrigt fungerar det bra!

Comments are closed.