Nutzung unseres Backup-Servers
Zur Nutzung unseres Backup-Server wird benötigt:
1.) Ein Account von uns. Wir arbeiten mit ssh als Übertragungsprotokoll für die Sicherung. Wir generieren einen Account auf einem unserer Backup-Server und einen ssh-key dazu, der auf dem zu sichernden Host installiert werden kann. Dies macht die Eingabe eines Passwortes beim Sicherungsvorgang überflüssig, birgt jedoch die Gefahr, dass ein Angreifer, der das zu sichernde System kompromittiert hat, auch Zugriff auf die Sicherung bekommt!
2.) Ein Script, das Ihr Filesystem mit allen Properties sichert. Es ist wichtig, beispielsweise "modification time", User-ID, Group-ID und Rechte zu erhalten. Folgendes Script erfüllt unter GNU/Linux diese Anforderung:
---
#!/bin/sh REMOTEUSER="kunde" REMOTESERVER="rsync2.net-lab.net"
echo "Moving existing backup file on remote server to backup-yesterday.tgz" ssh -c blowfish $REMOTEUSER@$REMOTESERVER 'if test -e ~/backup.tgz; then mv ~/backup.tgz ~/backup-yesterday.tgz; fi'
echo "Creating new backup.tgz on remote server" tar cj --atime-preserve --exclude="/proc/*" --numeric-owner --preserve --recursion / | ssh -c blowfish $REMOTEUSER@$REMOTESERVER 'cat - > ~/backup.tgz'
---
Es bleibt zu beachten, dass Datensicherung kein "no-brainer" ist. Es ist zu überlegen, was und wie man es sichern will. Ein häufig übersehenes Problem stellen offene Dateien dar, wie sie z.B. bei laufenden mysql- oder Postgresql-Datenbanken auftreten. Ebenso ist in obigem Script keine "Versionisierung" enthalten. Dies gilt es individuell zu lösen. Datensicherung ist wichtig! Im Zweifelsfall sprechen Sie uns bitte an! 3.) Sollten Ihre Daten sehr "sensitiv" sein, so empfiehlt es sich, den Datenstrom zu verschlüsseln, bevor (!) er auf unserem Backup-Server ankommt. Nicht mal die Admins unserer Backup-Server kommen dann an Ihre Daten ran! Jedoch sei an dieser Stelle ganz klar gesagt, dass wir Datensicherheit UND Datenschutz hoch halten und mit Sicherheit nicht in Ihren Datenbestand reingucken, es sei denn der Kunde wünscht dies (Einwilligung). In diesem Fall halten wir uns an die Zweckbindung der Einwilligung.
ssh-key
1.) Erzeugung eines ssh keys
root@kundenserver:~$ ssh-keygen -b 1024 -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
ee:ef:52:09:dd:cc:32:bb:7b:92:aa:1c:55:66:5a:f3 root@kundenserver
2.) Der Public-Key liegt nun unter /root/.ssh/id_dsa.pub
Er hat etwa folgende Form:
ssh-dss AAAAB3NzaC1kc3[..snip..snip.. ]acBw2yDcIXJWbKqlimCeWAvhA/0= root@kundenserver
3.) Der Inhalt des Public-Key von root@kundenserver wird nun ins Homeverzeichnis der Kundenaccounts@backup-server an folgende Position kopiert:
/home/kundenaccount/.ssh/authorized_keys [auf unserem Backup-Server!]
4.) Jetzt kann man ohne Eingabe eines Passworts sein Backup-Script starten.
