Welche Verzeichnisse auf'm Server backupen?

[bumer]

Hallo,

Welche Verzeichnisse sichert Ihr eigentlich auf Eurem Server?

Reicht es aus nur folgende zu backupen?

Code: Alles auswählen

/etc/
/home/
/root/
/var/log
/var/mail
/var/www/

Anhand dieser kann man ja eigentlich alles wiederherstellen, oder?
Ist man im Fall der Fälle auch rechtlich abgesichert? In diesem Fall spielen ja die Dateien unter /var/log/ die entscheidende Rolle, oder?

Viele Grüße,
bumer

[eggy]

Keine Datenbanken oder ähnliches installiert?

[bumer]

Keine Datenbanken oder ähnliches installiert?

Noch nicht. Aber dann würde sicherlich noch /var/lib/mysql hinzukommen.

By the way, wie lange muss ich die Log-Dateien aufbewahren?

[eggy]

Warum glaubst Du, dass Du Logfiles haben musst? Was willst Du mit ihnen belegen? Dass der Server irgendwann mal "richtig" installiert war? Oder dass jemand eingebrochen ist? In letzterem Fall die Platte lieber im Ganzen jemandem geben der sich damit auskennt. Nicht vergessen: Datenschutz beachten.

[heisenberg]

MySQL-Datenverzeichnisse direkt sichern erzeugt keine brauchbaren Backups. Dazu muss enweder das DBMS gestoppt werden, oder die DBs werden exportiert.

automysqlbackup bzw. autopostgresqlbackup sind hier hilfreich.

[bumer]

Warum glaubst Du, dass Du Logfiles haben musst? Was willst Du mit ihnen belegen?

Ich wollt nur mal einen groben Hinweis. Mit dem Thema Datenschutz/rechtliches habe ich noch vor mich zu beschäftigen.

automysqlbackup bzw. autopostgresqlbackup sind hier hilfreich.

Vielen Dank für den Hinweis.

Also sind, abgesehen von mysql, die folgenden ausreichend? (halt so ziemlich wie auf 'ner lokalen Maschine):

Code: Alles auswählen

/etc/
/home/
/root/
/var/log
/var/mail
/var/www/

[peppie]

Welche Daten vom Server gesichert werden müssen hängt vor allem von dessen Konfiguration ab.

Das ganze /etc Verzeichnis zu sichern ist auch nicht gerade sinnvoll. Dort sind zwar die meisten Konfigurationen gespeichert, aber die können auch in /usr/share/ oder in /opt/ liegen. /opt/ wird zwar heut zu Tage nur noch selten genutzt, möglich ist es aber. Für Mails wird gerne das /var/mail Verzeichnis genommen.

Wichtig ist: Jeder Server muss individuell gesichert werden, es gibt keinen "Königsweg".

Das einzige wo niemals Daten gespeichert werden sollten ist /tmp, zumindest keine Daten die dauerhaft gespeichert werden sollen.

[heisenberg]

Das ganze /etc Verzeichnis zu sichern ist auch nicht gerade sinnvoll.

Ich glaube mit Der Meinung bist Du ziehmlich alleine. /etc ist mal eines der wichtigsten Verzeichnisse schlechthin, dass lt. FHS der vorgehesehene Platz für jegliche Systemkonfiguration ist. (Natürlich gibt's noch Software, die Ihre configs an anderen Orten ablegt.)

[peppie]

Das ganze /etc Verzeichnis zu sichern ist auch nicht gerade sinnvoll.

Ich glaube mit Der Meinung bist Du ziehmlich alleine. /etc ist mal eines der wichtigsten Verzeichnisse schlechthin, dass lt. FHS der vorgehesehene Platz für jegliche Systemkonfiguration ist. (Natürlich gibt's noch Software, die Ihre configs an anderen Orten ablegt.)

Ja und? Nur weil etwas in /etc/ steht bedeutet es nicht, dass man es auch sichern muss. Das fängt schon damit an, dass bestimmte Konfigdateien nicht in /etc sind sondern in anderen Verzeichnissen z.B. /var/opt/ oder /usr/share.
z.B. eine xorg.conf, die kann (sofern überhaupt noch genutzt, bei Desktops) nicht auf ein anderes System umgezogen werden, weil man sonst sehr wahrscheinlich ein schwarzes Bild bekommen aufgrund der falschen Konfiguration.
Man kann die Konfiguration natürlich auch sichern, um es bei Bedarf zurück zuspielen auf dem gleichen System. Dafür eignet sich aber ein Komplettes Systembackup über z.B. dd viel besser.

[catdog2]

Dort sind zwar die meisten Konfigurationen gespeichert, aber die können auch in /usr/share/ oder in /opt/ liegen. /opt/ wird zwar heut zu Tage nur noch selten genutzt, möglich ist es aber. Für Mails wird gerne das /var/mail Verzeichnis genommen.

/usr/share wird vom Paketmanager kontrolliert, wenn du da was eigenes liegen hast ist das schon mal falsch. Unterhalb von /var liegt durchaus recht oft mal etwas Sicherungswertes, heisst nicht umsonst Variable data. /opt und /var/opt sollte man möglicherweise auch sichern aber das wird wohl kein Paket in Debian benutzen, bedeutet wenn man da was installiert hat weiss man das i.d.r. auch.

Ansonsten kommt es wie gesagt sehr darauf an was für Anwendungen laufen was und in welcher Form gesichert werden muss.

[TRex]

/etc/ zu sichern kostet fast nichts. Der Aufwand, da das relevante rauszuziehen, lohnt sich nicht. Die ganz coolen Kids installieren etckeeper und pushen das git dann auf den Backupserver.

[WPSchulz]

Bei den heutigen Plattengrößen lohnt es sich doch wirklich nicht, den Kopf darüber zu zerbrechen, ob man mit dem Nicht-Mitsichern von diesem oder jenem Unterverzeichnis ein paar MB spart. Lieber testen, ob man mit seiner Sicherung im Notfall wirklich etwas anfangen könnte.

[Meillo]

/usr/local wurde noch nicht genannt. Je nachdem wie der Admin diesen Verzeichnisbaum handhabt, hat's dort eine Menge zu sichernder Information oder gar keine.

/var wuerde ich tendenziell komplett sichern, da sonst die Liste der Unterverzeichnisse, die man nicht vergessen sollte, lang werden kann. Da fehlen mir bislang die Erwaehnungen von /var/spool/ und /var/lib.

[gbotti]

Über das, was sinnvoll ist oder nicht, lässt sich also streiten.

Ich mache bei Kundensystemen gerne ein GIT-Repository mit dem kompletten /etc-Ordner, was ich dann (bei Bedarf) an das entsprechende Redmine-Projekt mit anhänge. So kann ich belegen, dass jemand gepfuscht hat. Außerdem kann ich dann Änderungen schön mitverfolgen. Den Ordner bräuchte ich dann in der Regel nicht mehr mitsichern, was ich aber trotzdem mache.

Ich habe mir angewöhnt alle veränderlichen Daten unter /var abzuspeichern. Diese Daten unter /var sichere ich dann auch mit.

Logs verwalte ich auf Systemen, die mir wichtig sind, mit Logstash/Elasticsearch. Natürlich zum Teil anonymisiert. Ins Backup nehme ich die allerdings nicht auf. Das ist vom Datenschutz her manchmal echt schwierig. Obwohl die Vorratsdatenspeicherung...

Die Berechtigungen von Dateien und Programmen lasse ich vor dem Backup mit getfacl in eine Textdatei sichern. So kann ich sicherstellen, dass nicht "aus versehen" die Berechtigungen zerstört werden bzw. habe eine höhere Chance nach "dummen" Änderungen diese wieder richtig zu setzen.

Was ich momentan versuche umzusetzen ist alle Installationen mit Chef durchzuführen und somit zu "dokumentieren". Wenn ich also einen neuen Server aufsetze verwende ich immer wieder die selben Scripts und kann nachher noch nachvollziehen, was ich gemacht habe und in welcher Reihenfolge. Somit brauche ich den Programmteil auch nicht sichern, da ich aus den Chef-Scripten relativ schnell ein neu aufgesetztes System mit den selben Parametern erhalte. Das hilft auch ganz gut bei Beispielsweise Python-Paketen, die per "pip" installiert werden. Die geraten dann nicht mehr "in Vergessenheit"
Das klappt natürlich nur bei Servern, die ich konsequent damit aufsetze. Bei allen "alten" Sytemen speichere ich die Paketliste ab um diese im Zweifelsfall bei einer Neuinstallation schnell wieder Griffbereit zu haben.

Sollte ich Programme manuell installieren müssen, lege ich die Sourcen / Downloads erst mal unter /opt ab. Dieser Ordner wird auch gesichert.

Natürlich kommt es (wie bereits erwähnt) darauf an die eventuell laufenden Programme richtig zu sichern. Beispielsweise MySQL mit mysqldump oder LDAP mit slapcat.

Was allerdings dann noch viel wichtiger ist als ein Backup, das vermeintlich läuft, ist das regelmäßige Testen der Backups. Also mal einen mysqldump wieder einspielen, testen, ob eine .tgz-Datei wieder lesbar ist, ...

[heisenberg]

Was allerdings dann noch viel wichtiger ist als ein Backup, das vermeintlich läuft, ist das regelmäßige Testen der Backups. Also mal einen mysqldump wieder einspielen, testen, ob eine .tgz-Datei wieder lesbar ist, ..

Ja. So sagt es des die Schule des guten Administrators.

Und tatsächlich. Der Fall den ich kürzlich hatte, war der, dass eine DB auf einmal korrupte Daten hatte. Beim Zugriff auf diese DB ist der MySQL-Daemon abgeschmiert. DB-Dumps nach dieser Fehlerhaften DB sind nicht mehr korrekt durchgelaufen und haben dann gefehlt. Irgendwann nach ein paar Minuten hatte sich der MySQL dann wieder neu gestartet. Das ganze wurde dann durch einen Zufall entdeckt, bevor das Backup wirklich gebraucht wurde.

Folge: Für ca. 2 Wochen waren von ca. 50% aller DBs keine Backups da.

[bumer]

MySQL-Datenverzeichnisse direkt sichern erzeugt keine brauchbaren Backups. Dazu muss enweder das DBMS gestoppt werden, oder die DBs werden exportiert.

automysqlbackup bzw. autopostgresqlbackup sind hier hilfreich.

Das geht doch auch ganz einfach mit:

Code: Alles auswählen

mysqldump -u root -p --all-databases > backup.sql