Sicherung der Tabellen

[Joachim Raap]

Hallo, im Moment schraube ich an einer Anwendung, die mit einer Datenbank (MariaDB) arbeitet. Jetzt kam mir so der Gedanke einer Sicherung der Tabellen, die nach der Testphase sicher sinnvoll ist.
Nur weiß ich nicht, wie man so etwas bewerkstelligt (gibt es dafür SQL-Befehle??); zur Verfügung steht eine externe Festplatte, auf die ich die Sicherung gern ablegen würde.
Kann man das hinkriegen?

[af0815]

SQL Befehle nicht direkt. Es lässt sich oft mit den Mitteln die beim Server dabei sind lösen. Ich löse das meistens über zeitgesteuerte Scripts auf der Kommandozeile.

Mysqldump fällt mir das so ein.

Ev. was für dich
https://dokuwiki.tachtler.net/doku.php? ... p_-_skript
https://www.xperttimer.de/news/mysql-ma ... -bat-datei

[gladio]

oder schau doch mal bei auf den Doku-Seiten von Maria DB vorbei.
z.B. hier: https://mariadb.com/kb/en/backup-and-restore-overview/

[gladio]

Du kannst natürlich auch einfach das Datenbankverzeichnis kopieren.
Sollte unter Windows unter Programme-MariaDB 10.x - data zu finden sein und nicht gerade genutzt werden.

[theo]

Am einfachsten geht es für mich mit phpMyAdmin -> Exportieren.

[af0815]

Das beste ist das wo ein Restore auch funktioniert

[fliegermichl]

Backup:

Code: Alles auswählen

mysqldump DatabaseName -u username -ppassword > backup.sql

Restore:

Code: Alles auswählen

cat backup.sql|mysql DatabaseName -u username -ppassword

[theo]

Das beste ist das wo ein Restore auch funktioniert

Bezieht sich der Mr.Green auf phpMyAdmin?
Was geht denn da nicht, beim importieren? Ich hatte noch nie Probleme damit.
Vielleicht einen anderen SQL-Kompatibilitätsmodus wählen?

phpmy.png (49.31 KiB) 1301 mal betrachtet

[m.fuchs]

Das beste ist das wo ein Restore auch funktioniert

Exakt. Nach fünfzehn Jahren im Hostingbereich verlasse ich mich nur noch auf Datenbank-Backups im Textformat - SQL-Files, CSV, JSON oder XML.
Also alles, womit man auch manuell eine Chance hat Daten wiederherzustellen. Dafür haben schon zuviele andere Lösungen versagt.

Dazu kommen dann auch noch Tests. Ist die Backupgröße auch glaubwürdig im Vergleich zur Datenbank? Kann man bei SQL-Files einen positiven Syntaxcheck durchführen?
Funktioniert ein Restore in eine neue Datenbank und stimmen dann Stichproben-Abfragen in beiden System überein?

[af0815]

Der Mr. Green bezieht sich darauf, das man es auch probiert hat.
Ich habe schon erlebt, das das Desasterrecovery das Desaster war. Hat am neuen PC/Server ganz einfach nicht funktioniert. Deswegen immer mal auf einem anderen PC/Server testen.

[theo]

Der Mr. Green bezieht sich darauf, das man es auch probiert hat.
Ich habe schon erlebt, das das Desasterrecovery das Desaster war. Hat am neuen PC/Server ganz einfach nicht funktioniert. Deswegen immer mal auf einem anderen PC/Server testen.

Ich mache immer ein komprimiertes SQL-Format.
Wie auch m.fuchs sagt, funktioniert das meistens und sonst kann man noch "zu Fuss" etwas an der Datei ändern.

[fliegermichl]

Sehr beliebt sind auch schleichende Fehler bei dem dir das letzte Backup nichts nützt weil der Fehler schon seit einiger Zeit mitgesichert wurde.
Also die Backups im Textformat auch immer schön in ein Git Repo einchecken.
Dann kann man später auch verschiedene Backups per Patch zusammenführen und restaurieren.

[Joh]

Exakt. Nach fünfzehn Jahren im Hostingbereich verlasse ich mich nur noch auf Datenbank-Backups im Textformat - SQL-Files, CSV, JSON oder XML.

dazu fällt mir eine Episode mit 1blue ein:
(Virtuellen?) Server gemietet. Tägliche Komplettsicherung durch den Hoster.
Nach 3 Monaten bei einem nächtlichen Linuxupdate hat ein Festplattenfehler zugeschlagen.

Die Sicherungen befanden sich auf der gleichen Platte.
=> für mich glücklicherweise nur Test/Spieldaten weg.

Ergo: die Sicherungen dezentral speichern!

[m.fuchs]

Die Sicherungen befanden sich auf der gleichen Platte.

Wann war denn das?

[Joh]

10 years ago...

max. 15 Jahre; ich habe schon hier gewohnt / gearbeitet.

Mein Kontoauszug sagt: im November 2010