FAQ |
Kalender |
![]() |
#1 | ||
|
|||
Mycket flitig postare
|
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:
Vad tror ni? |
||
![]() |
![]() |
![]() |
#2 | ||
|
|||
Nykomling
|
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.
|
||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Mycket flitig postare
|
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. |
||
![]() |
![]() |
![]() |
#4 | ||
|
|||
Klarade millennium-buggen
|
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. |
||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Klarade millennium-buggen
|
Vet du vad ordet inkrementell betyder patrikweb?
|
||
![]() |
![]() |
![]() |
#6 | ||
|
|||
Mycket flitig postare
|
Citat:
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). |
||
![]() |
![]() |
![]() |
#7 | ||
|
|||
Klarade millennium-buggen
|
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å.
|
||
![]() |
![]() |
![]() |
#8 | ||
|
|||
Mycket flitig postare
|
ja det blir inkrementell backup på känsliga delar av sajten
|
||
![]() |
![]() |
![]() |
#9 | ||
|
|||
Mycket flitig postare
|
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. |
||
![]() |
![]() |
![]() |
#10 | |||
|
||||
Mycket flitig postare
|
Citat:
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 |
|||
![]() |
![]() |
Svara |
|
|