[Debian] Automatische offsite backups, hoe?

[Olaf van der Spek]

Ik heb een Debian server en ik wil graag automatische offsite backups implementeren.
Automatisch backups met cron zijn geen probleem, maar wat is de beste en veiligste manier om ze offsite te krijgen?
Op TLDP lijkt weinig te vinden over offsite backups en ook op de debian site zelf heb ik geen how to kunnen vinden.
FTP is geen optie omdat het geen secure protocol is.
SFTP zou kunnen, maar hoe creeer ik een restricted account op de destination host dat alleen maar files kan uploaden (en niet overschrijven) naar een enkele directory en geen shell of andere SSH subsystems kan gebruiken?
En is het mogelijk het later nog een keer te proberen als de destination host niet bereikbaar is.
HTTPS zou eventueel ook kunnen (pull vanaf de destination en met file encryptie), maar hoe weet ik wanneer de backup klaar is?

[blender]

Wat dacht je van rsync over ssh met certificaten?

[igmar]

scp met een scponly account
rdup
rsync

take a pick

[Olaf van der Spek]

igmar schreef op 13 september 2004 @ 21:57:
scp met een scponly account
rdup
rsync

take a pick

Maar hoe zorg ik ervoor dat scp alleen naar een bepaalde directory kan schrijven en geen bestaande bestanden kan overschrijven?

[mph_rbi]

rsync is your friend

[Wilke]

^^ with igmar.

rsync schijnt nogal de nodige beveiligingsproblemen gehad te hebben, ook recent nog als ik het me goed herinner. Maar is wel speciaal voor dit doel gemaakt, dus zeker onderzoeken - als het 'veilig genoeg' is, is het denk ik wel de handigste keus.

Misschien is het een optie om een 'passwordless' ssh login te gebruiken (zodat je kunt scp'en). Dat kan relatief veilig door gebruik te maken van RSA of DSA public/private keyparen. Door op de private key geen wachtwoord te zetten kun je passwordless inloggen van de client op de server (dus de client kan zo de files van de server kopieeren).

Ik hoef vast niet uit te leggen dat je dan screwed bent als de client vanaf waar je dit doet gehacked wordt (met de andere oplossingen is dit trouwens ook zo). Maar de communicatie zelf is redelijk goed beveiligd op deze manier.

[Olaf van der Spek]

Wilke schreef op 13 september 2004 @ 22:26:
Ik hoef vast niet uit te leggen dat je dan screwed bent als de client vanaf waar je dit doet gehacked wordt (met de andere oplossingen is dit trouwens ook zo). Maar de communicatie zelf is redelijk goed beveiligd op deze manier.

Is er geen optie om dat account op de server read-only te maken dan?

[ Voor 44% gewijzigd door Olaf van der Spek op 13-09-2004 23:49 ]

[usr-local-dick]

Ik hoef vast niet uit te leggen dat je dan screwed bent als de client vanaf waar je dit doet gehacked wordt (met de andere oplossingen is dit trouwens ook zo). Maar de communicatie zelf is redelijk goed beveiligd op deze manier.

Je kunt risico beperken door de rsync te laten lopen vanaf een client achter een NAT router, zodat de machine waar de keys op staan in ieder geval nooit direct te bereiken is. Alle beetjes helpen.
Ik backup ook diverse machine met rsync/ssh, sommige zijn 'echt' remote, maar bv. een aantal 1U servers zonder tapedrive doen ook zo hun backups naar een machine met een tapedrive.
Het voordeel van rsync is dat je het prima over dunne lijntjes kan draaien.

[usr-local-dick]

rsync schijnt nogal de nodige beveiligingsproblemen gehad te hebben, ook recent nog als ik het me goed herinner.

De meeste problemen zitten in het servergedeelte; als je rsynch over ssh draait heb je daar geen last van

[Olaf van der Spek]

Ik had ook nog het volgende idee:
Encrypt de backup file, symlink/copy/move hem naar een IP(A) en password protected web-dir en download hem gewoon.
Dan heb je geen gevaarlijke keys op de destination nodig.

Het probleem is dan alleen dat de destination niet kan checken of er een nieuwe backup is, omdat je met een vaste bestandsnaam zit.

[Coen Rosdorff]

OlafvdSpek schreef op 13 september 2004 @ 23:50:
Het probleem is dan alleen dat de destination niet kan checken of er een nieuwe backup is, omdat je met een vaste bestandsnaam zit.

Dan download je vanaf de client eerst een backup.txt ofzo. Daar kan je dan een nummer gebruiken, of de filename inzetten, en dan de vergelijken met laatst opgehaalde backup.txt.. Is best wel wat aardigs van te maken.

Of gebruik de --mirror optie van wget samen met de -c en -N optie.

[Verwijderd]

/me sluit zich aan bij de rsync methode, al heb je voor rsync over ssh alsnog een user nodig... Nog een methode (over ssh) is de volgende (passwordless key's (fout) of cached key passwords gebruiken (goed)):

code:

tar cpjf - /some/path/or/file | ssh backupuser@eenserver 'cd /some/other/path ; tar xvpjf -'

Het probleem is dan alleen dat de destination niet kan checken of er een nieuwe backup is, omdat je met een vaste bestandsnaam zit.

Een check op {A|M|C}time erbij doen mischien?

[ Voor 27% gewijzigd door Verwijderd op 14-09-2004 17:45 ]

[Seth4Chaos]

Wij maken op ons werk ook gebruik van een offside-backup van onze database. We hebben alleen wel alle backups eerst geencryped (geloof met PGP) voordat het de deur uit gaat (dacht met een scp). De keys hou je gewoon binnen de deur (en in de kluis) zodat mocht de offside server gehacked worden ze helemaal niets aan je bedrijfsdata hebben.