Verständnisfrage Backup Lösung

[AWOHille]

Hallo,

ich habe in den letzten Wochen viel zum Thema Server Backup gelesen. Auch habe ich mir sehr viele Lösungen angeschaut bzw. local getestet. So 100% sicher bin ich aber nicht, ob ich die optimale Lösung gefunden habe. Deshalb frage ich auch hier lieber mal nach. Dies sind meine Anforderungen:

- Backup der wichtigsten Daten täglich /var, /usr, /home

- Eigentümer und Dateiberechtigungen sollen erhalten bleiben.

- Bei einer Neuinstallation des Debian6 möchte ich, nach erfolgter Partionierung, nur die entsprechenden Daten wieder rüber kopieren, so das danach das komplette System wieder lauffähig ist. Müssen die entsprechenden Pakete wieder installiert werden?

- gesichert wird auf einem Online Server per SFTP oder FTPS.

Als recht einfach Lösung habe ich den Backup-Manager getestet. Ist diese eine optimale Lösung oder gibt es bessere Tools?

Womit läßt sich der Online Speicher am einfachsten mounten (SFTP oder FTPS - mit Kennwort), z.B. curlftpfs?

Gruß Hille

[rudelgurke]

Kann man recht einfach per "rsync" organisieren, einen Cronjob der einmal täglich durchläuft und gut ist.
Für die Datenbanken - Master -> Slave Replica und auf dem Slave die Dumps machen - wieder per Cronjob.

Ein Hinweis vielleicht noch - die /etc Verzeichnisse nicht vergessen, sonst kann man alles noch einmal neu konfigurieren. ;)
Gilt natürlich nur für Backups, bei Sicherheitsproblemen schleicht sich sonst der Fehler vielleicht wieder ein.

[ddm3ve]

Ich empfehle an der Stelle immer LVM und die Möglichkeit Snapshots zu ziehen.
Das macht eine Point in Time Recovery einfach möglich.
Alles andere wird niemals mehr ein Konsistenter Stand.

Bei Deiner Überlegung wurden übrigens Datenbanken vergessen.
Eine laufende Anwendung z.B. Datenbanken kann nicht zuverlässig auf FS Ebene gesichert werden, jetzt könne man wie von Rudelgurke genannt einen dump ziehen, hat aber auch hier, und da ist mysql sehr problematisch im Bezug auf Replikation, das Problem einen Konsistenten Stand zu erhalten.

Andere DBMSe können in einen Backupmode versetzt werden und schreiben die fortlaufenden Änderungen in z.B. bei Postgres WAL, Undo Tablespace etc.

Wie schon gesagt, erschlägt man einen vollständig Konsistente Sicherung über einen Snapshot. Gute Datenbanken kommen damit klar, schlechte muss man dann noch übers "Binlog" recovern.

[AWOHille]

Danke erst mal für die Antworten.
Die MySQL Datenbanken kann ich ja problemlos sichern. Wie sieht es aber mit den Benutzern aus. Müssen dieser wieder neu angelegt werden? Warum ist es eigentlich nicht möglich, das ganze Verzeichnis /var/lib/mysql zu sichern bzw. wieder zurück zu sichern?

Gruß Hille

[ddm3ve]

Wenn Du ein neues DBMS aufsetzt, sind darin weder Datenbanken, noch Tabellen geschweidenn Benutzer und deren Berechtigungen abgelegt. Daher müssen auch die Benutzer gesichert werden. Dito Betriebsystem.

Auf die Datendateien unter /var/lib/mysql herrscht ein ständiger zugriff durch das DBMS. Werden hier Änderungen zum Zeitpunkt der Sicherung, durchgeführt, so sind hinterher die Datenfiles korrupt und die Dateninkonsistent.

Simples Beispiel.

Die Datenbank hat meinetwegen eine gewisse grösse erreicht.
Durch zufall und Glück hat die Sicherung geklappt und die Datenfiles z.B. bei MyIsam, da gibt kann es eher passieren, dass die Datenfiles i.O scheinen und weiter verwendet werden können.

Also die Sicherung dauert z.B. 10 Minuten. Hierbei ist es egal ob auf FS ebene oder per Dump.
Ein Benutzer meldet sich an.
1. Minute,
stöbert durch den shop, 5 Minute.
Ändert z.B. seine Mailbenachrichtigungen,
setzt eine Bestellung ab, 8 Minute.

Dann könnte es passieren, dass z.B. der Benutzer zwar existiert aber die Bestellungen in der Sicherung nicht mehr vorhanden sind, weil die Sicherung der einen Datenbank von vielen, nur 3 Minuten gedauert hat.
Bei einem Restore wiederum ist zwar ggf. der Benutzer da, die Bestellung aber nicht mehr im System und das, obwohl die Bestellung sogar schon bezahlt wurde.

-> In der Tat, Du hast recht das kann auch im zeitlichen Verlauf passieren, denn man kann ja nicht kontinuierlich und unterbrechungsfrei sichern.
War auch nur als Einstiegbeispiel gedacht.

Theoretisch, praktisch wiederum kann Mysql mit Innodb in Binlogs schreiben und man kann point in Time recovern.

Kommen wir also zum Thema transnationale Verarbeitung commit, rollback.
Das liest Du dir bitte in geeigneter Fachliteratur durch.

Anderes Beispiel, warum ein konsistente Sicherung übers ganze System wichtig sein kann.
Stellen wir uns eine Webpplikation vor, mit der man Bildeten hoch laden kann etc.
Die Sicherung der Datenbank läuft rund 20 Minuten früher oder später als die Sicherung der Webinhalte.
Ein Kunde hat Bilder , Dokumente etc. hochgeladen welche ebenfalls in der Datenbank registriert wurden.

Jetzt haben wir im einen Fall entweder Dateien, die nicht in der Datenbank erfasst sind oder anders herum, Erfasste Dateien, die physisch nicht als Datei vorhanden sind.
Das nur, weil die Sicherung der Datenbank und der Webinhalte zu einem anderen Zeitpunkt abgelaufen sind. Sinnigerweise will man aber für eine Sicherung nicht die ganze Anwendung / Webserver stoppen.

Hier kommt der Vorteil der Snapshots ins Spiel.

Zur Einleitung eines snapshots wird der Datenbank ein kurzer Befehle mit gegeben um einen Writelock zu erhalten. Die Datenbank kann nichts mehr schreiben.
Der Snapshot, was eine exakte eingefrorener Stand der Daten ist, wird erstellt, die Datenbank wird wieder schreiend geöffnet, und man kann in aller ruhe eine Konsistente Sicherung eines Datenbestandes eines exakten Zeitpunktes erstellen.

Danach löscht man den snapshot wieder.

Das erstellen des snapshots inkl. einem write lock dauet i.d.R. nur wenige Sekunden.
Sofern nicht gerade so viel auf der Datenbank los ist, dass dieses Statement in einen Timeout läuft.

Beim der Engine InnoDb ist das weg sichern der Datenfiles sehr fatal, die Datenbank greift quasi ständig darauf zu und Änderungen sind hier die Regel.
Die Wahrscheinlichkeit tendiert zu 0, dass ein Innodb Datenfile bei laufender Datenbank gesichert, wieder genutzt werden kann. I.d.R. ist die Datei korrupt.

[AWOHille]

Hallo,

danke erst mal für deine ausführliche Anleitung. Rein theoretisch müsste doch aber folgendes machbar sein z.B über Cronjob.

1. MySQL stoppen
2. /var/lib/mysql sichern
3. MySQL starten

oder liege ich falsch?

Gruß Hille

[ddm3ve]

Ja, das ist möglich.

Die Frage ist halt, ob man im Hosting eine Downtime haben will / darf.
Wenn ja, ist dies der beste und unproblematischte weg.

Hat nur den Nachteil, z.B. spzeiell bei Innodb, dass die Datenbank die Caches wieder füllen muss. Das kann im schlimmsten Fall durchaus seine Zeit dauern, bis die Datenbank wieder performant antwortet.

[daemotron]

Rein theoretisch müsste doch aber folgendes machbar sein z.B über Cronjob.

1. MySQL stoppen
2. /var/lib/mysql sichern
3. MySQL starten

oder liege ich falsch?

Das funktioniert (fast*) problemlos, verursacht aber Downtime. Du kannst die Downtime noch minimieren, indem Du folgendes machst:

1. MySQL stoppen
2. Snapshot vom LVM machen, auf dem /var/lib/mysql liegt
3. MySQL starten
4. Snapshot mounten & Daten sichern
5. Snapshout umounten und löschen.

* solange man bei derselben MySQL-Version bleibt. Für ein Upgrade oder eine Migration funktioniert das nicht oder nur eingeschränkt


Ansonsten noch ein genereller Denkanstoß zu Backups: Vollständige und differenzielle Sicherungen sind ein guter und relativ sicherer Weg; inkrementelle Backups bergen ein höheres Risiko (da alle erzeugten Generationen für ein Restore benötigt werden - es darf also kein Backup in der Kette beschädigt sein). Für einen Server würde ich immer differenzielle Backups bevorzugen.

Für Konfigurationsdateien (/etc) gibt es noch eine gänzlich andere Möglichkeit:

Code: Select all

cd /etc
git init
git add .
git commit -m "Mein Konfigurations-Repo angelegt"
git remote add origin git@github.com:username/Config-Repo.git
git push origin master

Nach jeder Änderung der Konfiguration einfach folgendes machen:

Code: Select all

cd /etc
git add .
git commit -m "habe dasunddas geändert"
git push

Damit hat man nicht nur eine Sicherung aller Konfigurationsdateien, sondern kann auch eine vermurkste Konfiguration zuverlässig wieder auf einen vorherigen Stand zurücksetzen.

Kleiner Hinweis am Rande: Natürlich würde man seine Konfigurationsdateien nicht in einem öffentlichen Repo auf Github einlagern (man denke nur an /etc/passwd bzw. shadow, Mail aliases und was sonst noch so interessant sein könnte).

P. S. wenn Dir git nicht gefällt, schau mal http://www.rootforum.org/wiki/Konfigura ... Subversion an - dort ist eine Subversion-basierte Alternative beschrieben.

[AWOHille]

Der Downtime zwischen mysql stop - Backup - mysql start beträgt max. 5 sec. Da in der Nacht um 3.00 Uhr die Besucherzahlen gleich 0 sind, habe ich die Sache mit einem einfachen Script, welches per Conjob gestartet wird, gelöst. Sollte sich an der Größe der Datenbank entscheidendes ändern, so das der Downtime größer wird, werde ich eine eurer Möglichkeiten in Auge fassen.

Gruß Hille