Server Backup

[hobbyadmin]

Moin!
Mein erster Debian-Server läuft ja jetzt und ich bin etwas stolz, dass ich das geschafft habe : )
Als nächstes möchte ich ein Backup für den schlimmsten anzunehmenden Unfall einrichten.
Sprich, wenn der Server vollständig unter geht, z.B. durch Brand, Wasserschaden, Diebstahl, Kurzschluss, etc. möchte ich folgendes machen können:

1. Debian von CD neu installieren
2. Alle Aktualisierungen einspielen
3. Mein Backup einspielen
FERTIG

Die Frage ist, welche Verzeichnisse muss ich sichern, damit auch tatsächlich alle Daten, alle Einstellungen, alle installierten Programme problemlos zurück kopiert werden können?
Mir ist klar, dass ich /home, /etc, /media/daten sichern muss. Aber was sollte ansonsten noch dabei sein?

[uname]

Vor allen musst du dir auch die nachinstallierten Pakete irgendwie merken bzw. die Paketliste sichern

Auch solltest du eine automatische Backup-Software nutzen, die dich beim Backup unterstützt.
Und neben dem Backup solltest du von Zeit zu Zeit ein Restore z. B. auf einem Testsystem ausprobieren.
Auch sollte dein Backup ähnliche Sicherheitsanforderungen erfüllen wie dein System selbst.
Vor allen bei Verschlüsselung achte darauf, dasss du nicht am Ende den Schlüssel verloren bringst.

[mcb]

Mit Timeshift kannst du zusätzlich das komplette System sichern. Also root ohne /home /media ...

https://github.com/teejee2008/timeshift Dort steht es genau.

[uname]

Ich sichere nicht das gesamte System. Wenn man aber das ganze System sichert, hat man natürlich auch alle installierten Pakete und die Paketliste, die irgendwo unter /var gespeichert ist.

Aber egal für welche Lösung man sich entscheidet. Man sollte nach dem ersten Backup mal eine Wiederherstellung (Restore) auf einem Testsystem versuchen.

[mcb]

Ich sichere nicht das gesamte System. ....

Aber egal für welche Lösung man sich entscheidet. Man sollte nach dem ersten Backup mal eine Wiederherstellung (Restore) auf einem Testsystem versuchen.

Ja ich sichere auch nicht alles (irgendetwas fehlt dann aber immer).

- timehift ist gut um schnell / & /boot zu reparieren. Aber das erklärt die Doku besser als ich.

- ja den Restore testen - umbedingt

[schwedenmann]

Hallo

Die Frage die noch nichtgestelt wurde: welche Dienste laufen darauf ?
Das wäre dann bei der Sicherung auch zu bedenken.

Ansonsten kannst

1.Image estellen per dd, clonezila,partclone oder ähnlichen
2. EinArchiv der Dateien erstellen mit z.B. fsarchiver,dartar, ,borgabckup,oder öhnlichen backuptools
3. Alle Dateien ohne Komperssion,oder archiv quasi kopiern per rsync,timeshift,rsnapshot oder ähnlichem
4. nur /etc + Paketliste sichern, im fall der Fälle Debian neu installieren, /etc zurückspielen und die Pakete aus der Paketliste wieder zurückspielen


mfg
schwedenmann

[mcb]

....
4. nur /etc + Paketliste sichern, im fall der Fälle Debian neu installieren, /etc zurückspielen und die Pakete aus der Paketliste wieder zurückspielen


mfg
schwedenmann

Also /etc reicht ? Dort sind alle Systemsettings drinnen? Da muß ich mir auch noch was überlegen.

[schwedenmann]

Hallo

Also /etc reicht ? Dort sind alle Systemsettings drinnen? Da muß ich mir auch noch was überlegen.

es kommt auf dein setup an.

Normalerweise reciht fpr eine Server

1. netinstall
2. danach die entsprechenden Dienste wie:

samba
nfs-kernel-server
nginx
php
vsftp
mariadb


Wenn du danach das alte /etc zurückkopierst,hast die dieselbe Installation,wie vor dem Fiasko.

Beim dbms (also mariadb,postgresql) kann es ev. zu Problemen kommen,das hängt aber von dbms-setup ab und ob ev. zwischem alten Zustand des OS und dem backup ein majorrelease des dbms stattgefunden hat,dann kann obiger Weg zu problemen führen. Auch wo du die dbms-datenpfade hast,kann ev. ein Problem werden.


mfg
schwedenmann

[mcb]

Hallo

Also /etc reicht ? Dort sind alle Systemsettings drinnen? Da muß ich mir auch noch was überlegen.

es kommt auf dein setup an.

...

Wenn du danach das alte /etc zurückkopierst,hast die dieselbe Installation,wie vor dem Fiasko.

Beim dbms (also mariadb,postgresql) kann es ev. zu Problemen kommen,das hängt aber von dbms-setup ab und ob ev. zwischem alten Zustand des OS und dem backup ein majorrelease des dbms stattgefunden hat,dann kann obiger Weg zu problemen führen. Auch wo du die dbms-datenpfade hast,kann ev. ein Problem werden.


mfg
schwedenmann

Ah ok Danke! Wieder was gelernt.

[hobbyadmin]

Ok, danke.
Das hilft mir schon weiter.

Zu Eurer Frage:
Es ist bisher nur ein sehr sehr einfacher Backup-Server.
Als Dienst läuft bisher nur open-sshserver.
Die Backups kommen nur über SSH rein.

Wenn ich Euch richtig verstanden habe, brauche ich daher nur folgendes zu sichern:
/etc
/home
/media/daten

Mit welchem Befehl kann ich denn eine Liste der manuell installierten Pakete erstellen?
Und wie spiele ich das dann nach einer Neu-Installation wieder ein?

[schwedenmann]

hallo

Mit welchem Befehl kann ich denn eine Liste der manuell installierten Pakete erstellen?
Und wie spiele ich das dann nach einer Neu-Installation wieder ein?

siehe dazu
https://wiki.ubuntuusers.de/Paketverwaltung/Tipps/

bei deiner Installation reicht eigentlich die Grundinstalltion + apt-.get openssh-server, dann /etc zurückkopieren fertig.

/home sollte man nat. auch noch sichern,aber einem Server sidn dort eigentlich nur die ~/.bash.rc und nat.,fast vergessen ~/.ssh/ interessant

/media/daten ist das der Mountpoint für deine backuplatte, oder dein backupverzeichnis ?

falls /media/daten auf eine 2.interne HDD weist,brauchst du das nicht zu sichern,das ist ja dann schon gesichert.

mfg
schwedenmann

[mcb]

Zum Beispiel so:

Code: Alles auswählen

aptitude -F%p search '~i!~M!~v' >shopping-list.txt

apt install $(cat shopping-list.txt)

^^ in der Liste landen alle manuell (Nach-)installierten Pakete. apt install dann zum Neuinstallieren.

[hobbyadmin]

OK, danke!
Dann werde ich das so machen und auch mal die Wiederherstellung testen.
Ich wusste halt nicht, ob noch weitere Einstellungen für den ssh-Server oder für die Benutzer, in anderen Ordnern liegen.

Im Verzeichnis /media/daten liegen die Backup-Daten. Das ist leider keine externe HDD. Muss also auch gesicxhert werden.
Aber insgesamt scheint das ja bei meiner einfachen Konfiguration alles recht unblutig zu sein : )

[schwedenmann]

Hallo

Im Verzeichnis /media/daten liegen die Backup-Daten. Das ist leider keine externe HDD.

In bißchen komisch für ein backupverzeichnis

1. (n /media werden afaik meist,oder nur per automount Wechslemedien gemountet
2. nach /mnt kan alles gemountet werden,wäre also auch in Bertacht zu ziehen für ein backupverzeichnsi
3. gibt es noch /srv da kann man sowas (backups) auch hinmounten
4. oder so wie ich telweise, einfach z.B. /data oder /backup anlegen und dorthin mounten,bzw. backups kopieren

mfg
schwedenmann

[hobbyadmin]

OK,
ich kenne mich halt noch nicht so gut mit Linux-Servern aus.
Beim nächsten Mal werde ich aber /mnt oder /srv nehmen.
Ich wusste nicht, dass man normalerweise diese Verzeichnisse für ein Backup nimmt.

[MSfree]

2. nach /mnt kan alles gemountet werden,wäre also auch in Bertacht zu ziehen für ein backupverzeichnsi

Nun ja, du bist root, und damit kannst du dein System modifizieren und nutzen, wie du möchstest.

Ich für meinen Teil habe unter / ein Verzeichnis namens "pub" angelegt und mein RAID dahin gemountet. Analog kann man für das Backupverzeichnis auch

Code: Alles auswählen

su -
mkdir /backup
chmod 755 /backup

ausführen und die Platte/das RAID nach /backup mounten.

Es spricht nichts dagegen, im Wurzelverzeichnis zusätzliche Unterverzeichnisse anzulegen. Es ist nicht verboten und es kann der Übersicht dienen, nicht die immer vorhandenen Verzeichnisse /mnt und/oder /media zu verwenden.

Die zusätzichen Verzeichnisse werden auch nicht durch (dist-)upgrades zerstört.

[schwedenmann]

Hallo


@Msfree

Es spricht nichts dagegen, im Wurzelverzeichnis zusätzliche Unterverzeichnisse anzulegen. Es ist nicht verboten und es kann der Übersicht dienen, nicht die immer vorhandenen Verzeichnisse /mnt und/oder /media zu verwenden.

So hatte ich meine Ausführungen eigentlich gemeint. nach /media irgendwas,außer Wechselmedien zu mounten ist m.M. nach ungewöhnlich.Sowas wie Backups oder auch Datenverzeichnisse, oder shares landen bei mir entweder unter /srv oder in eigenen Verzeichnisse innerhalb von / wie z.B. /backup /data und dann darin noch Unterverzeichnisse für verschieden PC, oder backupprogramme oder serverdienste wie ftp,nfs,samba.

mfg
schwedenmann

P.S.
was ich überhaupt nicht verstehe beim Wurzelverzeichnis,daß sind die Verzeichnisse /var/www oder /var/lib/mysql oder auch /user/lib/nginx/http für http oder dbms.

[hobbyadmin]

Moin!
Das Backup ist eingerichtet und läuft jetzt jede Nacht automatisch durch. Es funktioniert völlig problemlos.
Ich habe nur noch eine Frage zu meinem Sicherheitskonzept.

Der Aufbau:
Ich habe einen kleinen Backup-Server aufgesetzt.
Dieser Backup-Server HOLT das Backup täglich vom Arbeits-Server ab.
Die Anmeldung erfolgt über SSH mit Key-Files.
Der Datentransfer erfolgt über Rsync.
Der Arbeits-Server hat dabei keinerlei Zugriff oder Anmeldemöglichkeit auf den Backup-Server.
Nur der Backup-Server darf und kann sich auf dem Arbeits-Server anmelden.
Ich wollte damit vermeiden, dass Schadsoftware sich selbst vom Arbeits-Server auf den Backup-Server verbreiten kann.

Meine Fragen dazu:
Was passiert nun wirklich, wenn der Arbeits-Server von z.B. Ransomware verschlüsselt wird?
Kann sich der Backup-Server dann nicht mehr über SSH beim Arbeits-Server anmelden? (Das wäre sehr gut, so wollte ich das haben)
Oder kann sich der Backup-Server weiterhin per SSH anmelden und holt dann die Ransomware-Schadsoftware per Rsync auf den Backup-Server? (Das wäre sehr schlecht)


Es wäre echt gut, wenn Ihr mich dazu aufklären könntet!

[schwedenmann]

Hallo

Oder kann sich der Backup-Server weiterhin per SSH anmelden und holt dann die Ransomware-Schadsoftware per Rsync auf den Backup-Server?

ich galube,das hängt davon ab ob

/ oder "nur" /srv (als datenverzeichnis) befallen,bzw. verschlüsselt wird.

Im Falle von /srv kann es sich immer noch mit dem Server verbinden.

mfg
schwedenmann

[MSfree]

Was passiert nun wirklich, wenn der Arbeits-Server von z.B. Ransomware verschlüsselt wird?
Kann sich der Backup-Server dann nicht mehr über SSH beim Arbeits-Server anmelden?

Das kommt drauf an, ob die Schadsoftware einfach dumm alle Dateien verschlüsselt oder ob der einige Dateien von der Veschlüsselung ausnimmt. Offenbar läßt sich ein verschlüsseltes System ja meist noch booten, eine Entschlüsselung nach Zahlung des Lösegelds wäre sonst ja auch noch schwieriger als ohnehin schon.

Ich könnte mir also gut vorstellen, daß auch SSH-Schlüssel von der Schadsoftware ausgenommen werden, damit man sich per rsync auch das Backup mit verschlüsselten Dateien zertrümmert. Abhilfe dagenen ist ein tägliches Vollbackup bzw. rsync mit --link-dest zu benutzen, und dabei alle bisher gemachten Backups stehen zu lassen. Dann kann man auch Backups wieder einspielen, die vor dem Schadsoftwarebefall entstanden sind.

Allerdings ist deine momentane Backupstrategie, die Images deiner VMs zu sichern, ziemlich ungeeignet, um damit täglich Vollbackups zu machen. Du soltlest die Datein deiner VMs sichern und nicht die Images. Das würde den täglichen Platzbedarf deiner Backups geschätzt um den Faktor 100 reduzieren und auch die Backupzeiten entsprechnd verkürzen. Ich habe z.B. auf meinem Backupsystem die Vollbackups der letzen rund 750 Tage stehen und ich habe noch geschätzt Platz, um weitere 2000 Tage zu speichern.

[Tintom]

Allerdings ist deine momentane Backupstrategie, die Images deiner VMs zu sichern, ziemlich ungeeignet, um damit täglich Vollbackups zu machen.

Das war auch schon im Vorgängerthread der entscheidende Punkt: viewtopic.php?p=1276501#p1276501

Das Programm, dass die Backups von der VM auf der Windows Maschine macht heißt "Veem" oder "Veam". Davon habe ich keine Ahnung und lasse die Finger da weg : )