Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

system:backup

Backups

Dein Uberspace wird automatisch jede Nacht vollständig auf einem externen Backupserver von uns gesichert, das betrifft sowohl deine Dateien, als auch deine MySQL-Datenbanken.

Auch wir kochen nur mit Wasser und ein Backup ist erst ein Backup, wenn es an mindestens zwei unterschiedlichen Orten liegt. Verlasst euch also bitte nicht komplett auf uns, sondern macht selbst Backups eurer Daten und legt diese an einem anderen Ort ab. Aktuell verteilen wir die Backups nicht über mehrere Rechenzentren, die Backupserver stehen am gleichen Ort wie die Server selbst. Wir überlegen bereits, ob und wie wir das in Zukunft am besten realisieren können.

Dateien

Die Befehle gibst du alle auf der Shell ein, mit der du dich per SSH verbinden kannst.

Auf dem Hosting-Server, auf dem dein Uberspace liegt, hast du direkten Zugriff auf das Backup, das du in /backup findest. So sieht das aus:

[elena@elementium ~]$ ls -ltr /backup/
total 56
lrwxrwxrwx  1 nobody nobody    7 Oct  7  2013 daily.0 -> current
dr-xr-xr-x 21 nobody nobody 4096 Jul  7 03:51 weekly.7
dr-xr-xr-x 22 nobody nobody 4096 Jul 14 03:52 weekly.6
dr-xr-xr-x 22 nobody nobody 4096 Jul 21 05:26 weekly.5
dr-xr-xr-x 22 nobody nobody 4096 Jul 28 05:29 weekly.4
dr-xr-xr-x 22 nobody nobody 4096 Aug  4 05:33 weekly.3
dr-xr-xr-x 22 nobody nobody 4096 Aug 11 05:31 weekly.2
dr-xr-xr-x 22 nobody nobody 4096 Aug 18 05:53 weekly.1
lrwxrwxrwx  1 nobody nobody    8 Aug 18 13:27 daily.7 -> weekly.1
dr-xr-xr-x 22 nobody nobody 4096 Aug 19 05:53 daily.6
dr-xr-xr-x 22 nobody nobody 4096 Aug 20 05:58 daily.5
dr-xr-xr-x 22 nobody nobody 4096 Aug 21 06:35 daily.4
dr-xr-xr-x 22 nobody nobody 4096 Aug 22 05:19 daily.3
dr-xr-xr-x 22 nobody nobody 4096 Aug 23 06:02 daily.2
dr-xr-xr-x 22 nobody nobody 4096 Aug 24 05:16 daily.1
dr-xr-xr-x 22 nobody nobody 4096 Aug 25 05:31 current

Du hast versehentlich dein Verzeichnis /var/www/virtual/elena/html/blog gelöscht, und zwar schon vor, sagen wir mal, drei Tagen (und dir ist es erst heute aufgefallen)? Das ist kein Problem, denn es gibt ja eine vollständige Kopie:

[elena@elementium ~]$ ls -ld /backup/daily.3/var/www/virtual/elena/html/blog
drwxr-xr-x 12 elena elena 4096 Dec 12 23:31 /backup/daily.3/var/www/virtual/elena/html/blog

Du kannst also mit den ganz normalen Linux-Bordmitteln wie ls, cp, rsync etc. mit dem Backup hantieren, zum Beispiel einen Restore durchführen. Mit rsync bietet sich sogar die schöne Möglichkeit zunächst eine Trockenübunung zu machen bei der erstmal noch nichts geändert wird:

[elena@elementium ~]$ rsync --dry-run --verbose --recursive --links --perms --times --hard-links --acls --xattrs /backup/daily.3/var/www/virtual/elena/html/blog/ /var/www/virtual/elena/html/blog/

Wenn die Ausgabe der rsync-Trockenübung für Dich gut aussieht, kannst Du danach das Backup einspielen:

[elena@elementium ~]$ rsync --verbose --recursive --links --perms --times --hard-links --acls --xattrs /backup/daily.3/var/www/virtual/elena/html/blog/ /var/www/virtual/elena/html/blog/

Wenn du Hilfe brauchst und dich auf der Shell (noch) nicht sicher genug fühlst, um dir ein Backup selbst wiederherstellen zu können, melde dich einfach bei uns und wir unterstützen dich gerne dabei.

Aufgepasst! Geht beim Zugriff auf die Backups bitte nicht über Symlinks, wie z.B. ~/html – das geht schief, denn die Symlinks zeigen im Backup natürlich weiterhin auf ihr eigentliches Ziel, also z.B. auf /var/www/virtual/$USER/html und nicht auf /backup/daily.4/var/www/virtual/$USER/html.

MySQL-Datenbanken

Alle MySQL-Dumps findest du unter /mysqlbackup/$DATUM/$DEIN_USERNAME. So sieht das dann aus:

[elena@elementium ~]# ls -l /mysqlbackup/
total 156
drwxr-sr-x 410 nobody nobody 12288 Aug 13 01:25 2014-08-13_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 14 01:26 2014-08-14_01-14-26
drwxr-sr-x 410 nobody nobody 12288 Aug 15 01:25 2014-08-15_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 16 01:25 2014-08-16_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 17 01:24 2014-08-17_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 18 01:24 2014-08-18_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 19 01:25 2014-08-19_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 20 01:24 2014-08-20_01-14-26
drwxr-sr-x 410 nobody nobody 12288 Aug 21 01:25 2014-08-21_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 22 01:25 2014-08-22_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 23 01:25 2014-08-23_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 24 01:25 2014-08-24_01-14-25
drwxr-sr-x 410 nobody nobody 12288 Aug 25 01:25 2014-08-25_01-14-25
lrwxrwxrwx   1 nobody nobody    19 Aug 25 01:14 latest -> 2014-08-25_01-14-25

Der Symlink namens latest zeigt dabei jeweils auf das aktuellste vollständige Backup. (Beachte aber, daß dieser Symlink während das Backup gerade erstellt wird nicht existiert.)

MySQL-Dumps können im Gegensatz zu den dateibasierten Backups nicht inkrementell angelegt werden; ein solches Feature gibt es in Dumps aus strukturellen Gründen schlicht nicht. Wir können hier von daher nicht die vollen 14 Tage rückwirkend an Daten anbieten wie beim dateibasierten Backup (schlicht deshalb, weil die Datenmenge dann zu groß wird), aber zumindest einige Tage halten wir immer vor.

Innerhalb der nach dem Datum benannten Ordner findest Du einen Ordner der so heißt wie Dein Username. Darin liegen dann wiederum einzelne Ordner für Deine Datenbanken, in denen dann die Dumps liegen.

[elena@elementium ~]# ls -l /mysqlbackup/2012-10-30_21-00-00/elena/
total 4
drwxr-s--- 2 root elena 4096 Oct 30 21:03 elena

Damit du nicht nur „alles oder nichts“ wiederherstellen kannst, sichern wir jede Tabelle in einer separaten Datei und komprimieren diese mit xz. So sieht das dann aus:

[elena@elementium ~]# ls -l /mysqlbackup/2012-10-30_21-00-00/elena/elena/
total 48
-rw-r--r-- 1 elena elena 1080 Oct 30 21:03 account.sql.xz
-rw-r--r-- 1 elena elena  832 Oct 30 21:03 openid.sql.xz
-rw-r--r-- 1 elena elena 3256 Oct 30 21:03 session.sql.xz
-rw-r--r-- 1 elena elena 1048 Oct 30 21:03 transaction.sql.xz

Du kannst insofern problemlos einzelne Tabellen einspielen, und zwar beispielsweise so:

[elena@elementium ~]$ xzcat /mysqlbackup/2012-10-30_21-00-00/elena/elena/account.sql.xz | mysql elena

Da deine MySQL-Zugangsdaten in deiner .my.cnf hinterlegt sind, bedarf es hier keiner Eingabe von MySQL-Zugangsdaten. Hast du dir versehentlich eine komplette Datenbank weggehauen? Auch kein Problem; du musst natürlich nicht jede Tabelle einzeln wieder einspielen:

[elena@elementium ~]$ xzcat /mysqlbackup/2012-10-30_21-00-00/elena/elena/*.sql.xz | mysql elena

Auch hier gilt natürlich: Wenn du Hilfe brauchst und dich auf der Shell (noch) nicht sicher genug fühlst, um dir ein Backup selbst wiederherstellen zu können, melde dich einfach bei uns und wir unterstützen dich gerne dabei.

Technische Hintergründe

Dateien

Die Sache ist relativ simpel: Wir führen nächtlich via rsync über eine verschlüsselte SSH-Verbindung eine vollständige Synchronisation des Servers mit allen Uberspaces auf ein separates System durch (mit Ausnahme der Datenbanken, die wir separat behandeln). Dabei verwenden wir pro Tag ein separates Verzeichnis: daily.0 ist sozusagen das „Arbeitsverzeichnis“; das aktuelle Backup letzter Nacht findest du in daily.1, in daily.2 das für den Tag davor, etc. - dabei legen wir Hardlinks an, damit eine Datei, die tagelang unverändert vorlag, auch nur einmal auf dem Backupserver liegt und nicht unnötig Platz verschwendet. Sobald sich eine Datei geändert hat, wird der Hardlink aufgelöst und zwei verschiedene Stände der Datei gesichert.

„Dateien“ umfasst hier also wirklich alles, sowohl die Inhalte deines DocumentRoots als auch deine Mails, deine Konfiguration etc.; wie gesagt, lediglich die Datenbanken behandeln wir separat.

Wir haben uns, nachdem wir im Lauf der Jahre mit verschiedensten Backup-Techniken und -Tools experimentiert haben, für eine Variante entschieden, die mit Abstand am einfachsten zu administrieren ist und keiner speziellen Tools bedarf, um auf die Backups zugreifen zu können. Sie ist zwar nicht die performanteste oder effektivste Möglichkeit, aber nach unseren Erfahrungen absolut „rock-solid“, und darauf kommt es bei einer Datensicherung schließlich an.

Die Backups werden initiativ von unseren Backupservern aus durchgeführt (d.h. nicht der Hosting-Server schiebt sein Backup dorthin, sondern der Backupserver zieht sich das Backup vom Hostingserver) und werden von unserem Backupserver aus via NFS read-only auf dem betreffenden Uberspace-Server gemountet. Wir haben das aus drei Gründen so realisiert:

  1. Auf diese Weise gibt es vom Hosting-Server aus gar keinen direkten Zugriff auf den Backup-Server. Das ist wichtig für den Fall, dass ein Hacker den kompletten Hosting-Server kompromittieren würde: Normalerweise könnte er das Backup dann gleich mit kompromittieren; hier ist das nicht möglich. Er müsste dann schon separat auch noch den Backup-Server hacken.
  2. Durch die Read-Only-Einbindung via NFS ist sichergestellt, dass du zwar jederzeit lesend Zugriff auf das Backup hast, aber eben nicht schreibend. Fälle wie „Sch…, jetzt habe ich mein eigenes Backup gelöscht“ kann es von daher also auch nicht geben.
  3. Da das Backup auf einem externen Server liegt, zählt es nicht zu deiner Quota, obwohl via NFS alle Berechtigungen der Dateien im Backup und damit auch die Eigentümerschaft bei dir liegt.

Der Vollständigkeit halber sei erwähnt, dass wir das Backup auch auf korrekte Funktion überwachen. Fälle wie „Oh, jetzt wo du ein Backup brauchst, merken wir gerade … der Backup-Job läuft aufgrund eines Bugs ja schon seit einem halben Jahr nicht mehr!“ (ja, alles schon bei anderen Providern erlebt) werden damit bei uns effektiv vermieden.

Bitte nicht wundern: Beim Zugriff auf die Backupdateien wirst du bei weitem nicht die gleiche Performance haben können wie beim Zugriff auf deinen produktiven Datenbestand - das ist schlicht der langsameren Übertragung via NFS geschuldet, und ein wenig auch der langsameren Performance der Backupserver (insbesondere während gerade aktiv Backups durchgeführt werden).

Datenbanken

Wir haben lange gerätselt, wie sich MySQL-Datenbanken am vernünftigsten sichern lassen. Ein dateibasiertes Backup fällt hier nämlich aus: Finden während des Backups schreibende Zugriffe auf eine Tabelle statt, so ist diese im schlimmsten Fall im Backup korrupt und damit völlig unbrauchbar. Die sauberste Möglichkeit ist, einen Dump einer Tabelle anzufertigen, also eine Textdatei mit genau den SQL-Statements, die eine Tabelle anlegen und mit dem derzeitigen Datenbestand füllen. Das funktioniert auch prima, hat aber den „kleinen“ Nachteil, das während dieses Dumps die Tabelle gesperrt („gelockt“) ist und keine Schreibzugriffe darauf stattfinden können - sicherlich kein Problem bei kleineren Tabellen; für Tabellen, deren Backup minutenlang dauert, aber sehr wohl. Wir haben unsere MySQL-Server auf den Hosting-Servern daher jeweils in einer Master-Slave-Replikation aufgebaut: Der Slave enthält stets eine komplette Kopie aller Daten und wird live synchronisiert. Geht es nun an die Backups, stoppen wir den Slave - der Master arbeitet dabei weiter! - ziehen uns Dumps von ihm und starten ihn anschließend wieder, woraufhin er sich automatisch wieder mit dem Master synchronisiert. Das liest sich alles simpler, als es faktisch umzusetzen ist - wenn du dich für die Details interessierst, kannst du dir unsere Postings auf blog.jonaspasche.com dazu anschauen.

system/backup.txt · Zuletzt geändert: 2016/03/11 15:35 von uber