En fundering angående backuper

Tjenare,

Har precis nyligen vart en duktig idiot som har slarvat med backuperna.
Förlorade massor av timmar konfigurationsjobb när jag inte hade en vettig backup av min klient.
Så nu efter många flera timmars konfiguration och fått tillbaks mitt liv på banan igen så började jag skriva på ett backup-script för min klient.
Hade tänkt att använda mig av rsync och ssh, precis som jag har på min server som backar upp all viktig data till en annan maskin i mitt nät.
Men så slog det mig att den lösningen jag har på min server inte är bra ur säkerhetssynpunkt.
För just nu har jag rsync med ssh som authentiserar sig med publik nyckel när den backar upp data till min backup-server. Detta innebär att mitt skript skyfflar över data utan att behöva uppge lösenord.

Sen fick jag ett paranoid-anfall och insåg, fuck om min server blir hackad.....root kontot ägt, då har dom även tillgång till min andra server med root dessutom, bara för att jag kör ssh med auto-authentification.

Börjar nu bolla med tankarna hur jag kommer runt detta problem.
Eftersom jag backar upp bland annat /etc och vill behålla alla filrättigheter så inser jag att jag får ett problem med mitt backupförfarande om jag kör en backup-user som inte är root.
Eftersom det finns filer där som t ex nedan fil:
-rw-r----- 1 root dovecot 1675 Nov 13 2011 ./ssl/private/dovecot.pem

Ovanstående fall skulle innebära att jag behöver lägga upp min backup-user även i dovecot-gruppen för att kunna backa upp den filen. Detta är iofs inget problem med administrativt blir det ett problem för att jag vill inte sitta och kolla upp hela tiden om det finns filer som backup-usern inte har rättigheter till.
Det skulle bli en del grupper som backup-usern måste vara medlem i tillslut.

Ett annat alternativ skulle vara att backupen först skyfflas till en annan katalog som sedan ger backup-usern rättigheter till de filerna, därefter tas filerna bort efter att backupen är gjord till remote-servern.
Men det känns inte heller optimalt, så nu undrar jag hur ni hade löst problemet?

rsync -a behåller väl ändå alla filrättigheter? Så om du kör exempelvis rsync -a /etc user@backup:backupkatalog/ så bör du ju få behålla alla filrättigheter i precis samma skick som de blir lästa från ursprungsdatorn väl?

Visst, de får fortfarande tillgång till root-kontot på din första dator, men kommer endast åt backup-kontot på den andra datorn istället.

Sen går det ju att köra rsync som daemon, då kan de inte längre logga in med samma konto/pass på backupdatorn, men frågan är väl huruvida det är säkrare eller ej.

Ett annat alternativ vore väl att använda tar för att göra en komprimerad backup som dessutom behåller alla rättigheter på filerna som sen skyfflas över som vanlig användare till backupdatorn. Dock är det väldigt bandbreddsineffektivt, och rätt platsineffektivt med.

Gah, visst har du rätt när det gäller rsync -a /etc backupuser@backupserver:/path
Att jag inte tänkte på det

Men komprimering är jag inte sugen på, ifall någon tar-fil blir korrupt, då blir det jobbigare att återställa.

Du kan konfigurera SSH på destination host att endast tillåta en nyckel att exekvera vissa kommandon - t.ex. just rsync. Detta borde ta hand om det största problemet med att en ägd dator leder till att flera ägs. Visst, en local exploit i rsync kommer fortfarande att förstöra din dag - men det det är ju i alla fall en avsevärt mycket högre tröskel.

Btw, är du inte väl paranoid m.a.p. korrupta packade filer? rsync kan konfas att checksumma. SSH förutsätter jag har en del inbyggt checksummande, men om jag skall vara helt ärlig har jag aldrig undersökt det närmare. Har dock överfört många filer via scp och det har aldrig strulat.

Nja, du får inte skapa filer som ägs av andra användare än dig själv, och grupper som du inte är med i. Så det är bara root som får göra det TS vill göra.


Jag kör med tar av just detta fallet, har en backup-användare per dator som endast har tillgång till /srv/backup/datornamn där de öser in en tar-fil med all data varje vecka. För att återställa är det bara att köra med -p på tar.

EDIT: Om du är orolig över bandbredd så om du kör samma filnamn ("backup.tar") varje gång så överför bara rsync delar av tar-filen som har ändrats - så du överför lika lite som utan tar. Du har även möjligheten att via cron-jobb då rotera och kopiera backup.tar så du har flera revisioner.

EDIT EDIT: Om en tar-fil blir korrupt är det bara den delen (filen) i den som blir korrupt. Du kan cat:a en tar fil och läsa direkt. Det är synd att kalla det komprimering då det är ett "arkiveringsformat" där du egentligen bara lägger filerna efter varandra med lite metadata mellan.

Testade just själv, du har helt rätt.

Däremot hade jag ingen aning om att rsync bara förde över ändringarna även på tar-filer, även om det känns rätt uppenbart i efterhand.

Tack för inlägget, ska testa och labba lite