Datenbank per Cron kopieren

[Loka]

Hallo,

ich würde gerne eine meiner Datenbanken von Server A auf Server B, zu einer bestimmten Uhrzeit, per Cron-Job kopieren.

Wie mache ich das?


Vielen Dank für eure Antworten.

[Joe User]

Kleines Beispielscript:

Code: Select all

#!/bin/sh
mysqldump --allow-keywords --complete-insert --order-by-primary --tz-utc -uroot  database > /tmp/database.sql
scp /tmp/database.sql user@ip:/tmp/
rm /tmp/database.sql
exit 0

Das Script dann per Cronjob auführen, fertig.

[tim-j-63]

Hallo Joe,

wie gebe ich bei SCP an, dass ein privater Key verwendet wird?

LG Tim

[Joe User]

Es wird automatisch der zum jeweiligen Zielsystem passende Key verwendet, sofern er bei dem User hinterlegt ist, der scp aufruft.
Ansonsten lässt sich ein Key wie bei ssh auch explizit per "-i keyfile" angeben:

Code: Select all

scp -i id_rsa quelle ziel

[larsi86]

Mahlzeit zusammen, ich habe gerade den Beitrag bei Google entdeckt und daher habe ich mich hier angemeldet. Ich habe ein ähnliches Problem.

Bei mir ist die Konstellation ein wenig anders, ich habe in einer VM (virtuelle Box) Debian 7 am Laufen und möchte ein Shell Skript mir schreiben, welches nach dem Aufruf automatisch sich per Key auf einen Server eingeloggt und anschließend das Backup von der MySQL Datenbank anfertigt und herunterlädt. Wie muss man dann das Shell Skript modifizieren?

Ich möchte wenn möglich das Skript nicht auf den Server ablegen, wo die Daten abgefragt werden. Ich dachte mir, dass ich dann automatisch wenn ich meine VM gestartet habe mir eine Arbeitserleichterung erstelle um mit ich sofort ein Backup von meiner Webseite herunterladen.

Vielen Dank im Voraus für eure Antwort und ein frohes neues Jahr! Gruß Lars

[Joe User]

Ungetestet, bitte nicht ohne aktuellem Backup ausprobieren:

Code: Select all

ssh -i id_rsa user@ip "( /usr/sbin/mysqldump --flush-logs --master-data=2 --lock-all-tables --delete-master-logs --allow-keywords --complete-insert --triggers --routines --events --order-by-primary --set-gtid-purged=OFF --tz-utc --hex-blob --all-databases -uroot )" | cat - > /tmp/mysqldump.sql

Die Optionen " --triggers --routines --events --set-gtid-purged=OFF" können je nach MySQL-Version und Konfiguration unnötig sein (oder zu Fehlermeldungen führen), bitte bei Bedarf selbst anpassen.

[larsi86]

Wie begrenzt man dies auf eine Tabelle? Ich habe den Code ein wenig modifiziert, wäre dies so richtig?

Beispiel:

Code: Select all

ssh -i id_rsa user@ip "( /usr/sbin/mysqldump --flush-logs --master-data=2 --lock-all-tables --delete-master-logs --allow-keywords --complete-insert --triggers --routines --events --order-by-primary --set-gtid-purged=OFF --tz-utc --hex-blob  -p db_name -uroot )" | cat - /tmp/mysqldump.sql

Und wie bekomme ich ein Zip Datei von den Homepage Daten hin, welches auch gleich heruntergeladen werden?

[Joe User]

Für einzelne Datenbanken müsste es dann so aussehen:

Code: Select all

ssh -i id_rsa user@ip "( mysqldump --allow-keywords --complete-insert --order-by-primary --set-gtid-purged=OFF --tz-utc --hex-blob -uroot  database )" | cat - > /tmp/database.sql

Kein zip aber tar+bzip2, ungetestet:

Code: Select all

ssh -i id_rsa user@ip "( cd /path/to/htdocs && tar -cjf - . | uuencode )" | uudecode -o /tmp/htdocs_backup.tar.bz2

[larsi86]

Mahlzeit Joe, erst mal vielen Dank für deinen Beitrag. Wenn dies so funktioniert, würde dies mir extrem viel Arbeit ersparen.

Ich werde dies über das Wochenende testen. Gibt es noch irgendwie eine Möglichkeit die Prozesse mit einer niedrigen Priorität zu starten, damit das System (wo sich eingeloggt wird) bei eventueller Last diesen Prozess nach hinten schiebt? Oder muss ich da erst die Prozessid nach dem Start ermitteln?

[Joe User]

Das ist mit diesem Weg schwierig, da die remote ausgeführten Befehle unter Umständen im Kontext des SSHd und der Loginshell laufen können und damit dann als jeweiliger Subprozess. Es ist mit Workarounds, etwa einem dedizierten limitierten Loginuser, machbar, aber es lohnt oft den Aufwand nicht.

Am Besten führt man diese Aufgaben zu Uhrzeiten durch, wenn potentiell am Wenigsten auf dem Server los ist (beispielsweise Nachts zwischen 3:00 Uhr und 5:00 Uhr).

Wenn man das Ganze nicht remote machen würde, wäre es sehr viel einfacher, stabiler und sicherer. Vor Allem muss man beachten, dass wenn die SSH-Verbindung abbricht auch das Backup mit abbricht und zu unvorhergesehenen Nebenwirkungen führen kann. Deshalb würde ich solche Lösungen nur für Notsituationen einsetzen und niemals als reguläres Backupkonzept.