Datenbanken richtig sichern

  • Hallo und alles Gute noch im neuem Jahr :)

    Ich hätte da mal eine Frage.
    Und zwar geht es um Backup und das sichern der Datenbank.

    Ich verwende das WBB in der Version 4.0.12.
    Gesichert habe ich die Datenbank bis jetzt immer mit dem "MySQLDumper phpBB3-Magic Edition Version 1.22"
    Vor langer Zeit habe ich mal zum testen eine andere WBB Version auf dem Server geladen und damit die Datenbank
    wiederherstellen wollen, aber das klappte nicht wirklich, Mein WBB sichere ich über die Einstellungen der Confixx.
    Klicke da immer mal wieder auf Backup.

    Irgendwie fühle ich mich damit nicht wirklich wohl.

    Wie sichert ihr eure Datenbanken und das WBB richtig?

    Vielen Dank.

    LG Thomas

  • Hi,

    ich habe durch den Hoster eine automatische Backup-Funktion, die auch super funktioniert.

    Früher habe ich die Daten vom Server manuell runtergeladen und die Datenbank über phpMyAdmin manuell exportiert.

  • G'day mate,

    ich sichere via Shell mit dem mysqldumper, aber dafür brauchste ja wie gesagt Shell-Zugang
    Beispiel:

  • Ich sichere auch nächtlich. Die Dumps werden bei mir zusätzlich komprimiert, via openSSL verschlüsselt und am Ende in mein Google-Drive geladen :)

    Hier das Script (ohne Google Drive):


    Hier das Script mit Google Drive (verwendet grive):


    EDIT:

    Als ich noch ein WBB betrieben habe, war der Code um ein paar Zeilen erweitert, sodass vor Beginn der Sicherung der Wartungsmodus aktiviert wurde und nach Abschluss deaktiviert, um Inkonsistenz zu vermeiden.

  • @Alexander Ebert

    Mit --single-transaction war ich mir bisher nicht sicher. Bin ich mir auch jetzt noch nicht :D

    Aber mit der Komprimierung hast du an für sich Recht. Wobei ich zwischenzeitlich am überlegen war, xz zu verwenden, da die Kompressionsrate noch einmal besser ist. Jedoch habe ich mich aufgrund der recht hohen Komprimierungszeit dagegen entschieden.

    @fluxX

    Kommt darauf an, was du möchtest. Möchtest du die Dateien klein halten, ungeachtet der Geschwindigkeit, verwendest du bzip2. Wenn dir Geschwindigkeit wichtiger ist als die Kompressionsrate, verwendest du gzip oder LZMA. Am Einfachsten wäre es aber sicherlich, es einfach mal auszuprobieren, da die tatsächlichen Ergebnisse von meiner Aussage abweichen können. Und wenn du dir noch etwas anschauen möchtest: 7z.

    Mir persönlich reicht gzip voll und ganz.

    • Offizieller Beitrag

    Mit --single-transaction war ich mir bisher nicht sicher. Bin ich mir auch jetzt noch nicht :D

    Solltest du aber, denn --single-transaction bewirkt einen globalen Checkpoint wodurch der resultierende Dump exakt dem Zeitpunkt entspricht zu dem der Dump gestartet wurde. Zum einen wird die Integrität gewahrt und zum anderen vermeidest du unnötige Locks auf Tabellen.

    Vor allem die Integrität ist wichtig, da Veränderungen an der Datenbank nach dem Start des Dumps ignoriert werden und du keine inkonsistenten Datenbestände hast. Ein Beispiel: Du hast 3 große Tabellen und durch eine Nutzeraktion werden in allen 3 Tabellen Daten abgelegt die zusammen gehören. Im Worst-Case wird diese Aktion durchgeführt als der Dump der 3. Tabelle anläuft, damit hast du die neuen Daten von Tabelle 3 im Dump aber nicht die Daten in Tabelle 1 und 2 da diese bereits abgeschlossen sind. Mit --single-transaction wird genau dies verhindert, da die Aktion erst während des Dumps passiert und somit hinter dem Checkpoint liegt.

  • Wenn du unbedingt zusätzlichen Speicherplatz sparen möchtest verwende 3, der Unterschied zu 9 ist praktisch nicht existent bis auf die vielfach längere Laufzeit.


    Hab gerade mal geschaut. Eine 397.4 MB große DB mit 9 zu sichern hält die Sicherungsdatei bei rund 24 MB, wogegen die Sicherung mit 3 eine 52 MB große Sicherungsdatei erzeugt. Ist also schon nicht ganz so gering der Unterschied, wie ich finde.

    • Offizieller Beitrag

    Hab gerade mal geschaut. Eine 397.4 MB große DB mit 9 zu sichern hält die Sicherungsdatei bei rund 24 MB, wogegen die Sicherung mit 3 eine 52 MB große Sicherungsdatei erzeugt. Ist also schon nicht ganz so gering der Unterschied, wie ich finde.

    Relativ gesehen ja, absolut gesehen macht es keinen Unterschied, gleichzeitig hast du aber einen massiv höheren Rechenaufwand beim Erzeugen und je nach Größe des Dumps und der Komplexität kann das richtig lange dauern. Die Datenbank von woltlab.com mit gzip -1 ist nur eine Frage von einer Minute, mache ich aber -9 läuft gzip erstmal für 10-15 Minuten (Intel Xeon E5-2620 v3, DDR4 2133 MHz / ECC-Registered Buffered). Wenn du wirklich Wert auf die Größe legst solltest du dir mal pigz anschauen, das erlaubt die Kompression über mehrere CPU-Cores hinweg wodurch der Zeitaufwand ordentlich eingedampft wird.

  • Mein Backup läuft so ab:

    1. Sicherung der Datenbank mit dem MySQLDumper, die Sicherung wird auf dem FTP abgelegt
    2. ich sicher den FTP mit dem Datenbankbackup per Shell
    3. ich lade das Komplettbackup auf meinen PC

    Wenn ich wieder was einspielen will mache ich das komplett per Shell

    Das klappt super so :)

  • Hallo!

    Als ich noch ein WBB betrieben habe, war der Code um ein paar Zeilen erweitert, sodass vor Beginn der Sicherung der Wartungsmodus aktiviert wurde und nach Abschluss deaktiviert, um Inkonsistenz zu vermeiden.

    Es wäre super nett, wenn Du die Zeilen für den Wartungsmodus nennen würdest.

    Ich nutze automysqlbackup per Cronjob. --single-transaction habe ich in der Config dazu per 'yes' aktiviert. Macht der Wartungsmodus dann zusätzlich noch Sinn, oder ist dies bei InnoDB in Kombination mit --single-transaction nicht notwendig? Wobei ja die Konsistenz einerseits des Backups zählt, aber auch die "anschließende" Konsistenz der aktiven Datenbank - könnte diese Schaden nehmen, wenn jemand posten möchte, während das Backup läuft? Dann wäre der Wartungsmodus wieder vorbeugend hilfreich.

    Zusätzlich frage ich mich immer wieder, ob ich immer auch die weiteren Tabellen (information_schema und performance_schema) auch sichern soll.

    Gruß + Danke

    Gruß aus Südhessen

  • Zusätzlich frage ich mich immer wieder, ob ich immer auch die weiteren Tabellen (information_schema und performance_schema) auch sichern soll.


    Halte ich für unnötig. Deswegen auch Datenbanken richtig sichern


    Hallo,

    @SoftCreatR Lade die Zugangsdaten mit --defaults-file. Das vermeidet das awking und die Übergabe des Passworts als Parameter.


    Ich selbst nutze das so eh nicht, da ich gar nicht wirklich weiß, ob debian-sys-maint Zugriff auf alles hat. Da ich jedoch davon ausgehe dass es sich um einen Root-Account handelt, habe ich das zu Demonstrationszwecken in den Code oben gepackt. Aber danke für den Hinweis :)

    @thomasnrw

    Ich habe das Thema mal in den OT-Bereich verschoben. Dir geht es zwar um die Sicherung der WBB-Datenbank, jedoch ist die Frage selbst ja recht allgemein.

  • Speichere momentan immer via Plesk und lade es direkt mit einem Mausklick auf meinen PC und ins Ftp (verschlüsselt und komprimiert).

    Mysqldumper läuft noch nicht unter php7 soweit ich weiß. Hatte es selbst mal getestet.

  • Ich selbst nutze das so eh nicht, da ich gar nicht wirklich weiß, ob debian-sys-maint Zugriff auf alles hat.

    Ich sichere seit mind. einem Jahr mit --defaults-extra-file=/etc/mysql/debian.cnf  in diesem einfachen Script auf einen externen Backup FTP und funzt tadellos. Da ich nur ein Forum auf dem Server laufen habe, ist es natürlich ziemlich schlicht gehalten. Ausserdem wird mir ein Symlink angelegt, so kann ich mit last immer zum aktuellen Ordner. Muss aber noch zusätzlich sagen dass ich vielleicht ein wenig zu paranoid bin, denn ich sichere alle 2 Std :)

    Gruß

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!