bueges
Anmeldungsdatum: 25. Oktober 2021
Beiträge: Zähle...
|
Hallo ich möchte meinen Rasberry Pi verwenden um ein Netzwerk Verzeichnis zu sichern. Hintergund :
Ich habe das Netzwerk Verzeichnis per mount Befehl vorher eingebunden. Nun habe ich mir ein Python Script geschrieben, das folgenden Befehl ausführt :
| logging.info("kopiere daten von " + source_folder + " nach " + current_backup)
shutil.copytree(source_folder, current_backup)
logging.info("✅ daten erfolgreich kopiert")
|
Leider bricht das Script nach ca. 7 Stunden ohne Fehler ab. Allerdings sind noch nicht alle Dateien kopiert worden.
Daher bin habe ich ein bisschen mit rsync herumgespielt.
Nun wird der Befehl so ausgeführt :
| logging.info("kopiere daten von " + source_folder + " nach " + current_backup)
cmd = "rsync -a " + source_folder + " " + current_backup
os.system(cmd);
logging.info("✅ daten erfolgreich kopiert")
|
Nun werden die Daten kopiert aber es dauert schon relativ lange ca. 6 Stunden. Ich experimentiere nun mit dem tar Befehl - habe aber noch keine ergebnisse. Was möchte ich eigentlich :
Ich möchte per Cron Job das Skript 2x in der Woche ausführen, sodass 2 Backups vom source folder gemacht werden. Ältere Backups sollen und werden auch schon gelöscht.
Das Backup soll als zip oder tar in backup Verzeichnis - auch das geschiet schon Nun meine Frage gibt es einen bessere Weg - als vorher die Daten per rsync zu kopieren (in das Backup Verzeichnis), dann das Verzeicnis zu zippen Hier das gesamte Backup Sript. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51 | def _logCopyTree(path, names):
logging.info('kopiere %s' % path)
return [] # nothing will be ignored
if (os.path.exists(log_file)):
os.remove(log_file)
logging.basicConfig(format='%(asctime)s %(message)s', filename=log_file, encoding='utf-8', level=logging.INFO)
logging.info("-----------------------")
logging.info("backup script gestartet")
logging.info("Parameter source_folder : " + source_folder)
logging.info("Parameter backup_folder : " + backup_folder)
if (len(os.listdir(source_folder)) == 0) :
logging.warning( "❌ keine daten in " + source_folder + " gefunden")
else:
current_backup = os.path.join(backup_folder, datetime.now().strftime("%Y-%m-%d_%H-%M-%S"))
# TODO catch exception
logging.info("kopiere daten von " + source_folder + " nach " + current_backup)
cmd = "rsync -a " + source_folder + " " + current_backup
os.system(cmd);
logging.info("✅ daten erfolgreich kopiert")
# TODO catch exception
logging.info("erstelle tar archiv " + current_backup + ".tar")
current_backup_archive = shutil.make_archive(current_backup, "tar",current_backup )
logging.info("✅ tar archiv erfolgreich erstellt")
logging.info("lösche backup verzeichnis : " + current_backup)
try:
shutil.rmtree(current_backup)
except PermissionError as e:
errorMsg = "❌ PermissionError beim löschen : " + str(e)
logging.error(errorMsg)
logging.info("✅ backup verzeichnis erfolgreich gelöscht")
backups = os.listdir(backup_folder)
tar_backups = [backup for backup in backups if backup.endswith('.tar')]
tar_backups.sort()
if len(tar_backups) > 2:
oldest_backup = os.path.join(backup_folder, tar_backups[0])
logging.info("lösche tar archiv : " + oldest_backup)
os.remove( oldest_backup)
logging.info("✅ tar archiv erfolgreich gelöscht")
logging.info("beende backup script")
|
Für eure Anregungen und Tipps bedanke ich mich schon mal
|
ChQdEwrOd
Anmeldungsdatum: 15. November 2023
Beiträge: 6
|
Da machst du ein weites Feld auf.
Was ist mit inkrementellen oder differentiellen Backups?
Schon die Komprimierung getestet im Bezug auf Auslastung des kleinen Berry? Deine Kernfrage ist, ob es schneller gehen könnte, richtig? Oder was stört dich an der gefundenen Lösung? Wie sieht es mit der Netzwerkverbindung aus? Wifi? Ethernet? Gigabit oder 100MBit? Rsync an sich ist schon eine ziemlich performante Sache, erfordert aber auch etwas Rechenleistung, könnte sein, dass der Berry dafür etwas schwach ist, keine Ahnung. Was sagt den [h]top während des Vorganges? Viel IOWait? Man kann natürlich auch mit CPIO durch SSH pipen, aber so weit ich mich erinnere, ist das nur wenig schneller als Rsync, da rsync an sich schon sehr ausgefeilt ist...
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4634
Wohnort: Berlin
|
@bueges: Als erstes mal würde ich in Frage stellen wollen warum man für so etwas wichtiges wie Sicherungskopien etwas eigenes basteln muss, statt etwas fertiges gut getestetes zu nehmen. Dann fehlen bei dem Quelltext mindestens mal die Importe und die Definitionen von Dateinamen und Pfaden. Dafür ist _logCopyTree() irgendwie über. Wobei sich der Name dieser Funktion nicht an die Namenskonvention hält: Namen werden in Python klein_mit_unterstrichen geschrieben. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Um if -Bedingungen gehören keine unnötigen Klammern. Eine Datei auf Existenz prüfen bevor man etwas damit macht ist in der Regel falsch, denn zwischen Prüfen und etwas damit machen, kann sie ja gelöscht werden. Das heisst man muss mit dieser Ausnahme sowieso umgehen können. Wenn man die aber behandelt, dann ist der vorherige Test unnötig. os und os.path ist aber auch gar nicht mehr das Mittel der Wahl seit dem es das pathlib -Modul gibt. Und da kann man der Löschmethode direkt sagen das eine nicht-vorhandene kein Problem ist.
os.system() sollte man dagegen noch nie verwenden. Man weiss zum Beispiel nicht ob ein Rückgabecode dort vom gestarteten Programm kommt, oder von der Shell in der das gestartet wurde. Und was man da übergibt wird von einer Shell interpretiert, man muss also auf alles mögliche wie Leer- und Sonderzeichen achten die eine besondere Bedeutung für eine Shell haben können.
current_backup_archive wird definiert, aber nirgends verwendet.
Wenn beim löschen eines Verzeichnisbaums ein Rechteproblem auftritt, ist es komisch danach dem Benutzer zu sagen das erfolgreich gelöscht wurde. Ich sehe auch irgendwo nicht denn Sinn erst mit rsync etwas zu kopieren was man gleich danach wieder löscht‽ Ungetestet:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62 | #!/usr/bin/env python3
import logging
import shutil
import subprocess
from datetime import datetime
from pathlib import Path
LOG_FILE_PATH = Path("…")
SOURCE_PATH = Path("…")
BACKUP_PATH = Path("…")
def main():
LOG_FILE_PATH.unlink(missing_ok=True)
logging.basicConfig(
format="%(asctime)s %(message)s",
filename=LOG_FILE_PATH,
encoding="utf-8",
level=logging.INFO,
)
logging.info("-----------------------")
logging.info("backup script gestartet")
logging.info("Parameter source_folder: %s", SOURCE_PATH)
logging.info("Parameter backup_folder: %s", BACKUP_PATH)
if not next(SOURCE_PATH.iterdir(), None):
logging.warning("❌ keine daten in %s gefunden", SOURCE_PATH)
else:
backup_path = BACKUP_PATH / f"{datetime.now():%Y-%m-%d_%H-%M-%S}"
# TODO catch exception
logging.info("kopiere daten von %s nach %s", SOURCE_PATH, backup_path)
subprocess.run(
["rsync", "-a", str(SOURCE_PATH), str(backup_path)], check=True
)
logging.info("✅ daten erfolgreich kopiert")
# TODO catch exception
logging.info("erstelle tar archiv %s.tar", backup_path)
shutil.make_archive(backup_path, "tar", backup_path)
logging.info("✅ tar archiv erfolgreich erstellt")
logging.info("lösche backup verzeichnis: %s", backup_path)
try:
shutil.rmtree(backup_path)
except PermissionError as error:
logging.error("❌ PermissionError beim löschen : %s", error)
else:
logging.info("✅ backup verzeichnis erfolgreich gelöscht")
tar_file_paths = sorted(BACKUP_PATH.glob("*.tar"))
if len(tar_file_paths) > 2:
oldest_backup_file_path = tar_file_paths[0]
logging.info("lösche tar archiv: %s", oldest_backup_file_path)
oldest_backup_file_path.unlink()
logging.info("✅ tar archiv erfolgreich gelöscht")
logging.info("beende backup script")
if __name__ == "__main__":
main()
|
|
homer65
Anmeldungsdatum: 8. November 2005
Beiträge: 557
Wohnort: bochum, germany
|
Komprimieren mit tar macht Sinn, wenn die Ausgabe spürbar kleiner ist als die Eingabe.
Wie ist denn das Verhältnis bei Dir?
Auch wenn Du wenige Backups aufbewahren willst. Könnte das Komprimieren viel Plattenplatz sparen.
Ich mache Backups immer per tar cfvz <ausgabe> <eingabe>
Gruß Christian
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4634
Wohnort: Berlin
|
Wobei so eine 400 GiB-Sicherung in ein Tar aber auch ziemlich nervig sein kann wenn man nur eine oder ein paar wenige Dateien aus der Sicherung wiederherstellen möchte.
|
homer65
Anmeldungsdatum: 8. November 2005
Beiträge: 557
Wohnort: bochum, germany
|
Marc_BlackJack_Rintsch schrieb: Wobei so eine 400 GiB-Sicherung in ein Tar aber auch ziemlich nervig sein kann wenn man nur eine oder ein paar wenige Dateien aus der Sicherung wiederherstellen möchte.
Ist halt die Frage was einem wichtiger ist und wie häufig man den Restore macht. Wenn man 2x pro Woche Backup und höchstens einmal jährlich Restore ausführt, wäre meine Meinung ein komprimierter Backup ist sinnvoller. Auch dauert das Kopieren von vielen kleinen Dateien über ein Netzwerk deutlich länger als das Kopieren einer großen Datei.
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4634
Wohnort: Berlin
|
@homer65: Letztlich würde ich bei der Datenmenge aber auch erwarten, dass sich da nur ein geringer Teil wirklich ändert, womit das nur beim ersten Backup wirklich die volle Zeit braucht. Und wenn man dann Links auf unveränderte Dateien legt, kann man da locker mehrere ”volle” Backups haben die am Ende wahrscheinlich kleiner sind als immer wieder alles als komprimiertes Archiv da rüber zu schieben. Ganz abgefahren wäre es wenn man statt sich selbst was zu basteln, eine ausgereifte Software zum Sichern verwendet die, inkrementell arbeitet, und sowohl komprimiert, als auch schnellen Zugriff auf einzelne Dateien bietet. 😎
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12981
|
Bei solchen Volumina und regelmäßigem Backup per Skript wirst Du mit Borg viel glücklicher. Der größte Vorteil für Dich dürfte sein, dass Borg nur Änderungen überträgt und nicht alle Dateien (wie es, wenn auch komprimiert, mit tar passiert). Das gibt eine massive Zeitersparnis. Und ungeänderte Dateien werden nur ein Mal auf dem Ziel gespeichert (Deduplizierung). Mit Borg ist es viel einfacher, einzelne Dateien wiederherzustellen; Du mountest das Zielrepository und kannst dann mit jedem beliebigen Dateimanager oder der Shell navigieren, lesen und kopieren.
|
PcDoc2000
Anmeldungsdatum: 4. Februar 2010
Beiträge: 860
Wohnort: Wien
|
Marc_BlackJack_Rintsch schrieb: @bueges: Als erstes mal würde ich in Frage stellen wollen warum man für so etwas wichtiges wie Sicherungskopien etwas eigenes basteln muss, statt etwas fertiges gut getestetes zu nehmen.
Was hast du denn gegen etwas selbst gebasteltes? Wenn es ihm Spaß macht ist doch gut so und man lernt meist auch was dabei. Wo ich dir aber vollkommen recht gebe ist: Marc_BlackJack_Rintsch schrieb: Ganz abgefahren wäre es wenn man statt sich selbst was zu basteln, eine ausgereifte Software zum Sichern verwendet die, inkrementell arbeitet, und sowohl komprimiert, als auch schnellen Zugriff auf einzelne Dateien bietet. 😎
Das schreit doch förmlich nach incremental backup. Wenn nicht mehrere Backupversionen gebraucht werden, arbeite ich auch gern mit Sync in nur eine Richtung. Da kann man dann je nach SW auch einstellen ob Dateien gelöscht werden sollen die in der Quelle gelöscht wurden, sollte man dahingehend bedenken haben. Der größte Nachteil ist da aber, dass sich mit der Zeit immer mehr "gelöschte" Dateien ansammeln im Backup.
|
Marc_BlackJack_Rintsch
Ehemalige
Anmeldungsdatum: 16. Juni 2006
Beiträge: 4634
Wohnort: Berlin
|
Ich habe nicht grundsätzlich etwas gegen Selbstgebasteltes, die Frage ist halt wie viel Spass das macht wenn man die Fehler genau dann herausfindet wenn man das Backup braucht. So kann man natürlich auch was lernen, aber muss man‽ 😈
|
fork991
Anmeldungsdatum: 26. Mai 2010
Beiträge: 58
|
Ich schließe mich meinen Vorschreibern an: Mit rsync und darauf aufbauenden oder ähnlichen Lösungen ist man da mit Sicherheit sehr gut bedient. Bei 400 GB wird man nicht glücklich, wenn man jedes Mal die kompletten Daten kopieren möchte. Das dauert extrem lange. Dass man hier ein Netzwerk mit weniger als 1000 MBit Netzwerkbandbreite verwendet, sehe ich hier nicht als sinnvoll an. Empfohlene Lösungen - nach meiner persönlichen Präferenz - passendste Software an erster Stelle: borg (Vorteile: Deduplizierung, Client erledigt das Backup) rsnapshot (Vorteile: Einfaches Kommandozeilen-Backup auf der Basis von rsync) BackupPC (Vorteile: Deduplizierung, Kompression, Web-GUI)
Normalerweise ist BackupPC mein Favorit. Da aber der Sicherungsserver hier ein Raspi ist, ist das nicht geeignet. Der ist da zu schwachbrüstig dafür.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12981
|
fork991 schrieb:
Mit rsync und darauf aufbauenden oder ähnlichen Lösungen ist man da mit Sicherheit sehr gut bedient.
Zumal man unveränderte Dateien nicht erneut hochladen muss, sondern Hardlinks erzeugen lassen kann.
Bei 400 GB wird man nicht glücklich, wenn man jedes Mal die kompletten Daten kopieren möchte. Das dauert extrem lange. Dass man hier ein Netzwerk mit weniger als 1000 MBit Netzwerkbandbreite verwendet, sehe ich hier nicht als sinnvoll an.
👍
Empfohlene Lösungen - nach meiner persönlichen Präferenz - passendste Software an erster Stelle: borg (Vorteile: Deduplizierung, Client erledigt das Backup) rsnapshot (Vorteile: Einfaches Kommandozeilen-Backup auf der Basis von rsync) BackupPC (Vorteile: Deduplizierung, Kompression, Web-GUI)
Borg bietet ebenfalls Kompression, Verschlüsselung und ein CLI.
Normalerweise ist BackupPC mein Favorit. Da aber der Sicherungsserver hier ein Raspi ist, ist das nicht geeignet. Der ist da zu schwachbrüstig dafür.
Ja, ich denke, da will man etwas konsolebasiertes nutzen. Restic ist - von der Papierform jedenfalls - ähnlich zu Borg, aber damit habe ich keine Erfahrungen.
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8740
|
rklm schrieb: Restic ist - von der Papierform jedenfalls - ähnlich zu Borg, aber damit habe ich keine Erfahrungen.
Da gibt es sehr viel für und wider im Netz. Aber restic soll sehr speicherhungrig sein.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17508
|
Restic oder Borg, alles andere skaliert nicht. Und niemand eine Backup "Software" selbst schreiben, das ist ein bereits gelöstes Problem bei dem man sich nur in den Fuß schießt.
|
fork991
Anmeldungsdatum: 26. Mai 2010
Beiträge: 58
|
Meine Antwort zum Thema RESTIC vs. Borg wurde hierhin verschoben: https://forum.ubuntuusers.de/topic/wahl-einer-backup-software/
|