[emilv]

Originally posted by Tobab@Sep 28 2008, 09:27
Man tar ju för givet att allt backupas om man har en VPS där backup ingår...

För det första är det inte särskilt smart att ta något för givet när det gäller backuper. Det är i slutändan du själv som drabbas om backuperna inte fungerar, så det ligger i ditt intresse att kolla upp allt när det gäller backupsystemet. Frågor som bör ställas till en backup-leverantör (även om leverantören är densamma som din vanliga leverantör av tjänsten) innefattar till exempel:
* Vad tar ni backup på?
* Hur ofta tar ni en backup? Hur ofta tar ni en full respektive en inkrementell backup?
* När gör ni det? Tidpunkt?
* Hur länge sparar ni backuperna?
* Vad kostar en återställning?
* Kan ni återställa katalog/program/funktion/operativsystem X till sitt urpsrungliga läge efter ett hårdvarufel? (Där X är något du är extra mån om och troligen inte kan klara att återskapa utan informationen i backupen)

Är du riktigt orolig bör du göra en teståterställning under normal drift, även om den kostar en liten slant, för att testa kvaliteten på backupleverantören.

För det andra så spelar det inte alltid någon roll att de gör en full backup av den virtuella maskinen. Även om man skapar en exakt snapshot av hur hårddisken såg ut vid backuptillfället så finns det funktioner som inte går att garantera en återställning för. Ett typexempel är just databasen, vilken kan vara mitt uppe i en transaktion när backupen görs och vid en återställning kan det då vara så att filerna är korrupta.

Värst är det om man gör en backup som inte är helt och hållet atomisk, dvs man kopierar en fil åt gången medan systemet är i drift. Så här kan då ett problem uppstå:
Säg att databasen har två filer den lagrar data i. Den har även en tredje fil där den lagrar att den lyckats med en viss transaktion. En transaktion går (i mitt exempel) till så här:
* Uppdatera fil 1
* Uppdatera fil 2
* Lagra i metadatafilen att vi lyckats med transaktionen.
Ponera då att vår filbackup kopierar filerna i den här ordningen:
* Fil 2
* Fil 1
* Metadatafilen

Om vi då kopierar fil 2 innan en transaktion påbörjas, men fil 1 och metadatafilen när transaktionen är klar så kommer vi att få en korrupt databas. Fil två kommer ju inte innehålla någon information om den här transaktionen! I värsta fall kan den här typen av fel göra att backupen är omöjlig att återställa. Databassystemen är sällan byggda för att klara en filbackup. När en transaktion "lyckats" så garanterar databasen att informationen är skriven till disk och den ska då (med en bra lagringsmotor, typ InnoDB) klara att man rycker ur sladden ur maskinen. Men att rycka ur sladden ur maskinen skiljer sig från en filbackup, eftersom när sladden rycks ur så har ju både fil 1 och 2 uppdaterats (alternativt så har metadatafilen inte uppdaterats ännu och då bör databasen kunna rulla tillbaka transaktionen).
Vill du slippa göra en dump av databasen och ändå få med den i en backup så får du alltså se till att välja ett databassystem som klarar detta, men skyll inte på backupleverantören för att ditt databassystem inte gör det.

Den enda VPS-backup jag kan tänka mig som garanterat skulle kunna återställa precis alla applikationer och hela VPS:en till sitt ursprungsläge är en snapshot av både maskinen och dess disk vid ett givet tillfälle, och en återställning till exakt detta läge (inklusive processorläge och RAM-minne). En sådan backup skulle dock bli dyr och opraktisk. Den skulle ta onödigt mycket plats på disk, den skulle vara svår att göra inkrementell (en full backup tar massvis med plats jämfört med en inkrementell) och om du bara vill göra en filåterställning krävs det ändå att du gör en återställning av hela maskinen och kör båda parallellt för att hämta ut de filer du vill ha (vilket resulterar i en dyrare och långsammare återställning). Ett sådant backupsystem skulle säkert kosta mer än hela VPS:en.