Jag kommer förmodligen snart att köpa en Dell Poweredge 1U server som jag tänkt ställa hos Crystone.

Jag skulle vilja ha kommentarer på den backuplösning jag tänkt mig, jag har aldrig administrerat en server förut:

• Raid-1, två stycken 80Gb SATA diskar
• 3:e hårddisk för incremental backup med rsync
• Månatlig backup på DVD (laddar hem allt)

Vad tror ni?

Låter bra, kan ju vara en idé att rsynca till en disk utanför servern / serverhallen om hemskheter som t.ex. brand eller stöld skulle inträffa.

Ja det skulle man kunna göra iofs..

Det blir bara 2 diskar som är speglade, samt en rsync som kör incremental på dom.

Funderar först hur du ska få in 3 diskar i DELL 1U servrar, vad jag vet har dom inga 1U med 3 diskar. Isåfall får du köra en extern disk.

Kör du riktiga system som Unix/Linux kan du smidigt göra snapshot eller spegling, full kopia av disken som du lätt kan flytta över via nfs, ftp eller direkt till extra disk.

Kör du en RAID1 behöver du inte köra full backup varje dag riktigt, kanske räcker exportera db (Om du nu kör någon) och filerna som ändrats.

Vet du vad ordet inkrementell betyder patrikweb?

Som sagt så blir det 2 diskar i dell's 1U.

Med riktigt system vet jag inte vad du menar? Jag tänkte köra Debian med software Raid 1 (spegling).

Sen kör jag incremental på det för att ha olika uppsättningar av de filer som ändras. Annars riskerar jag att ha en raid1 spegling på 2 st filer som ändå är trasiga. Använder jag incremental sparas flera revisioner av dessa filer.. t.ex. 7 st incrementals i veckan (enbart de som ändrats).

Ja men man kanske inte vill ha full inkrementell backup? Utan välja enstaka filer, export av db kallar jag inte inkrementell backup. Delvis inkrementell backup låter fult, bättre säga att ta backup på vissa filer. Rå filerna etc för mysql är helt onödigt ta backup på.

ja det blir inkrementell backup på känsliga delar av sajten

Månatlig backup till DVD låter sällan. En gång i veckan skulle jag nog ta (om inte datat ändras extremt sällan). Om det inte är för mycket data så skulle jag tanka över det till en annan burk på annan fysisk plats varje natt typ.

Just because you're paranoid it does not mean they're ain't after you...

Raid speglig isig är ingen backup. Hela raiden kan mycket väl dö och sabba båda diskarna mer eller mindre. Så backup varje dygn till annan fysisk maskin är att föredra. Och om den maskinen står i samma fysiska lokal så flytta data till DVD (eller annat medium) till annan lokal minst en gång i veckan.

Det är nog lämpliga riktlinjer för att kunna sova gott.

Varför är det bättre att säga backup på vissa filer?

Jag vet inte riktigt om du förstår eller inte vad ordet betyder.

Om du har ett system där filer ändras (förrutom i självaste /tmp och /var/tmp, eller där du lagrar sessionsdata), så är det bra att ta backup på filer som har ändrats sen senaste backup. Det är vad inkrementell backup är.

Så har din / 3 434 342 343 filer och du har ändrat bara 1, när du kör inkrementel backup på / backas bara 1 enda fil. Så, jag förstår inte krångligheten. Det är faktiskt bättre att överlåta det till mjukvaran än att sitta där och bestämma vad man ska ta backup på (enstaka filer som du sa) för att sedan komma på att du totalt glömt något superviktigt (säg till exempel /etc/passwd ).

Sen förstår jag inte varför man inte skulle ta backup på råfilerna? MySQL är inte direkt som Sybase eller Oracle och får spader om man byter datafiler.

Kör man din metod måste du först innan du tar backup, dumpa din databas så att du får datat.

Sen om det kraschar måste du läsa tillbaka filen och importera den i MySQL.

Kör du råfiler behöver du inte komma ihåg att dumpa den innan, och det är bara att läsa tillbaka råfilen och starta om mysql.

Fast, jag säger inte att din metod suger. Den kan vara användbar. Säg att du supit bort en tabell. Allt annat i databasen har blivit uppdaterat rätt mycket sen senaste backup. Då är det nog smidigt att kunna läsa in en tabell bara.

Jag har faktiskt en ännu bättre lösning för mina viktiga mysql-databaser.

Jag har ett skript som har en lista med databaser att hålla reda på. Vid en periodisk tidpunkt startas skriptet och kör genom listan. Först dumpar den databasen. Sen kollar den i den konfigurerade CVSROOT-en ifall den databasen varit dumpad tidigare. Om inte så skapar den en CVS-modul för den databasen. Nästa gång skriptet körs dumpar den databasen igen. Sen jämför den dumpen med den versionen som är dumpad tidigare. Om det är densamma gör den ingenting. Om databaser skiljer sig, checkar den in den nya versionen i CVS-en.

Anledningen varför jag skrev det skriptet är att jag upptäckte att det var knöligt att göra inkrementell backup på mysql själv. Antigen dumpade du databasen eller inte. Med andra ord, varje gång du gör en databasbackup så gör du fullbackup. (Tyvärr har inte mysql transaktionslog som andra riktiga databaser). Men CVS har ju möjlighet att lagra bara skilnader.

Så nu har jag ett skript som gör att jag lätt kan köra backup varje halvtimma på en databas på flera gig utan att min disk blir full direkt.

/Zoran

Inte för att jag har några problem med backuper eller lagring men det var en mycket intressant lösning. Tack, man lär så länge lever. ;)

Strålande zoran. Versionshantering rockar. Jag använder faktiskt delvis samma metod (automatisk CVS incheckning och sen körs backupen, vanlig periodisk på hela CVS-mappen).

Det är lite beta och inte särskilt genomtänkt, men jag planerar att köra en dedikerad backupserver på sikt som samlar in data från alla mina maskiner (och sen får man köra dvd-backuper från den då tex).

Fast då skall jag köra SubVersion, för h-e vad mycket bättre det är än CVS. Helt seriöst, dumpa CVS åt skogen och testa subversion, det är helt strålande att tex använda i Windows för utveckling, integrerar jättefint i skalet och är allmänt mysigt.

Jo, du har helt rätt. Subversion är mycket trevligt. Det jag framförallt tycker är bra att kataloger kan versionshanteras, det är lättare att ändra namn på filer och behålla historik osv.

Iallafall, om intresset finns kan jag väl slänga upp backupskriptet för MySQL så behöver ni bara kanske göra mindre ändringar istället för hacka från scratch.

/Zoran

Zoran, gör gärna det så får min programmer titta på det. Skulle uppskattas.

Lite OT kanske. Men Jag vetifan om jag tycker att en riktig hårdvaru raid är säkrare än en mjukvaru raid. För säg att man kör en raid på 2 diskar på ett raidkort och raidkortet pajar.
Då måste man jaga på ett likadant kort för att det ska funka. Men kör man däremot en mjukvaru raid så är det bara plugga in dom i närmaste fungerade maskin och kopiera datan.


Annars tycker jag du har en rätt bra lösning faktiskt. Jag hade väl tagit backuper på hela hårdiskarna en gång i månaden och sedan gjort backuper på alla ändrade filer varranan dag och lagt på ett annat ställe. Altså utanför rummet för att förhindra stöld och brand etc.


Varför finns det inga lösningar med dubbla raidkort? Dom pajar ju dom med ibland.


/ Tommy

Vad jag vet så finns det lösningar att köra dubbla raid kort och få det "ihop", men i detta fallet är det inget 24/7 kritisk sak som kostar några miljoner i timmen om det går ner.

Riktiga kritiska servrar kör inte med vanliga raid kort utan kör mot stora SAN, oftast dubbla SAN som står i olika städer med 2 X fiber bara in till serverparken.

Att man behöver liknande raid kort om det pajjar är väl det minsta problemet, om man inte kör något riktigt antikt.

Okej, jag har lagt upp en revision (vet inte om det är det senaste men...)

...på http://www.maiyk.net/zoran

Ladda ner och testa. Editera config-filen för egna behov.

/Zoran

En annan synpunkt på backuper, sparas, hur länge? Låt säga att jag tar fulla backuper med incrementals imellan och varje månad/vecka skriver ut detta till DVD. Hur länge ska jag spara detta tycker ni? Vem av mina kunder blir idag glad av backup från februari 2004?

Beror väl på verksamhet, och vad man har för avtal mot kund.

Bruka köra som standard spara fulla månadsbackup alla fall 6-12månader och dagliga backup 3 månader.

Vissa specialla saker kanske man vill ha backup några år tillbaka som handlar om olika versioner av något.

Det här är väl inkorrekt?

En mycket snygg lösning på up-to-the-second backup av MySQL-databaser är att
1. dumpa databasen till backupserver och gör RESET MASTER
2. skriv binärloggen till backupservern (eller en andra hårddisk)

Om databasen kraschar så har du på backupservern den senaste fulla backupen plus binärloggen. Applicera binärloggen på databasen så är du tillbaka mer eller mindre precis där du var när primärmaskinen gick ner.