Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

Support RSYNC BACKUP - MV_Backup.sh (Linux - Bash)

Ja ich habe erstmal meine Version auf die aktuellste Version migriert :smile:
Und jetzt habe ich das Problem das ein Profil was mit der ganzen Sache nichts zu tun hat nicht mehr funktioniert.
Als Fehler wird angegeben: FEHLER! Option -p wurde nicht korrekt definiert!
Dabei ist das Profil genau wie 2 andere nur das halt andere Pfade gesichert werden und der Profilbuchstabe anders ist. Was brauchst du da um das zu debuggen?

Das Profil für das Remote-Backup mittels Rsync-Daemon habe ich auch getestet. Ich habe dafür einfach den Modus auf "Daemon" gestellt und unter "target"
Code: 
"${mount[nr]:-$MOUNT}remote-ip::pladde"
eingefügt
Leider endet das Profil mit einem Fehler. Hier die Ausgabe:
Code: 
root@xxxx:~#  /root/MV_Backup.sh -p g
  MV_Backup (rsync) => Version: 190903 by MegaV0lt, http://j.mp/1TblNNj
  Original: 2011 by JaiBee, http://www.321tux.de/
  Gefundene Konfiguration:      ./MV_Backup.conf


  Konfiguration von:    gesamt_cubie_remote
  Sicherungsmodus:      => rsync-Daemon
  Quellverzeichnis(se): /Quellpfad
  Zielverzeichnis:      remote-ip::pladde
  Log-Datei:            remote-ip::pladde/2019-09-12_gesamt_cubie_remote.log
  Ausschluss:
                        /ausnahmen1
                        /ausnahmen2
                        /ausnahmen3
                       
  eMail-Versand an:     beispiel@test.de

  Profil "gesamt_cubie_remote" wird in 5 Sekunden gestartet
  Zum Abbrechen [Strg] + [C] drücken
  Zum Pausieren [Strg] + [Z] drücken (Fortsetzen mit "fg")

Sicherung startet (Profil: "gesamt_cubie_remote")
/root/MV_Backup.sh: line 658: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.log: No such file or directory
/root/MV_Backup.sh: line 658: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
/root/MV_Backup.sh: line 659: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.log: No such file or directory
/root/MV_Backup.sh: line 659: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
  Starte Sicherung (rsync)…
/root/MV_Backup.sh: line 661: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
/root/MV_Backup.sh: line 661: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory


  Profil "gesamt_cubie_remote" wurde mit Fehler (1) abgeschlossen (09/12/2019 08:11:20 PM)
  Weitere Informationen sind in der Datei:
  "remote-ip::pladde/2019-09-12_gesamt_cubie_remote.log" gespeichert.

/root/MV_Backup.sh: line 930: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
  Erstelle Archiv mit 1 Logdatei(en):
  "/tmp/MV_Backup.s9I1/Logs_2019-09-12-2011.tar.xz"
tar: remote-ip\:\:pladde/2019-09-12_gesamt_cubie_remote.log: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
/root/MV_Backup.sh: line 948: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
  Erzeuge eMail-Bericht…
ls: cannot access 'remote-ip::pladde': No such file or directory
/root/MV_Backup.sh: line 1017: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
du: cannot access 'remote-ip::pladde': No such file or directory
/root/MV_Backup.sh: line 1020: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
du: cannot access 'remote-ip::pladde/*/': No such file or directory
/root/MV_Backup.sh: line 1022: remote-ip::pladde/2019-09-12_gesamt_cubie_remote.err.log: No such file or directory
  Sende eMail an beispiel@test.de…
Sep 12 20:11:20 pve sendEmail[58940]: WARNING => The argument after -xu was not valid username!
Sep 12 20:11:20 pve sendEmail[58940]: WARNING => The argument after -xp was not valid password!
Sep 12 20:11:20 pve sendEmail[58940]: Email was sent successfully!

  Sicherungs-Bericht wurde mit "sendEmail" an beispiel@test.de versendet.
    Es wurde(n) 1 Logdatei(en) angelegt.


Sicherung(en) abgeschlossen.

Wo kann ich denn angeben wo die Logs gespeichert werden?
 
Zuletzt bearbeitet von einem Moderator:
Die Log-Datei muss Lokal erstellt werden, weil das Skript auf "remote-ip:ladde" ja keinen Zugriff hat! Sieht man id der Meldung ja ganz gut. Zum Beispiel:
Code: 
       log[nr]="/tmp/$(date +%F)_${title[nr]}.log"
Das steht in der jeweiligen Profiikonfiguration!

Zu den Profilen:
Wenn nur ein Profil definiert ist, kann man das -p weg lassen, weil das Skript dann automatisch dieses Profil verwendet.
Bei mehreren Profilen muss man -p angeben oder -a für alle Profile.

PS: Das Skript speichert bei Fehlern alle gesetzten Variablen in /tmp (*.env). Da kannst man sich ansehen welche Variablen gesetzt waren. Vielleicht erkennt man da was.

PPS:
Zum testen kannst Du das jeweilige Profil ja in einer eigenen *.conf eintragen und das Skript mit -c Aufrufen um diese *.conf zu verwenden
 
Hey MegaVolt..
Wirklich geniales Script, perfekt um Backups auf meine NAS zu schieben..
Habe ich den Ablauf richtig Verstanden..
Ich führe das Script zB Stündlich per Cron aus, es werden nur geänderte Dateiendie in "source" definiert werden auf die NAS geschoben?
Also nicht einfach jedesmal der komplette Ordner auf die NAS geschoben? Zu finde in "_DATEIEN"
Lösche ich eine Datei im Quell Verzeichnis is diese auf der NAS unter "Geloeschte Dateien" zu finden?

Viele Grüße
 
Das ist richtig! Man kann dann noch zusätzlich dei alten Daten für x Tage aufheben lassen (Vorgabe). Einfach mal testen...
 
Kommt drauf an. Es kann auch ohne root Rechte gehen. Das musst Du ausprobieren

-d gibt an wie alt die gelöschten Dateien max. sein sollen, bevor sie endgültig gelöscht werden
 
Perfekt, läuft prima..
Eins würd mich noch interessieren, ist es auch möglich das Profil so zu konfigurieren das man vom entfernten Server via SSH sich die Files auf die NAS holt
Ganz nach dieser Anleitung:
Sie müssen registriert sein, um Links zu sehen.
 
Habe ich nicht getestet. Müsste aber gehen wenn man die Parameter entsprechend eingibt (rsync_opt[nr]).
Zum testen kann man ja auch --dry-run mit angeben ;-)
Zum testen den Normal-Modus nehmen. Eventuen auch mal den "Daemon-Modus". Im Daemon-Modus leegt das Skript im Ziel keinen Ordner für gelöschte Dateien an. Und versucht auch nicht _Dateien zu erstellen.
 
Guten Tag,
ich nutze dieses Backup Script nach wie vor, habe aber da eine Neuschaffung anstand dieses jetzt nicht hinbekommen.
Kurze Erklärung hatte es auf 2 Qnaps am laufen ohne Probleme in den vielen Jahren, die Qnaps mußten aus Altersgründen einer Synology DS1621+ weichen.
Jetzt bekomme ich dieses Script nicht mehr zum laufen auf der DS1621.

Was braucht ihr damit ihr mich unterstützen könnt..?

Das Script sieht momentan so aus, welches ich einsetze, die Werte sind nur durch die DS 1621 ersetzt worden ansonsten 1 zu 1 von den Qnap übernommen worden.
# = = Profil 1 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
nr=1 # Fortlaufende Profil-Nummer
title[$nr]="FHEM-Sicherung-DS1621"
arg[$nr]="r"
mode[$nr]="" # Modus (Normal, Snapshot oder Multi)
source[$nr]="/opt"
mount[$nr]="" # Eigener Einhängepunkt
ftpsrc[$nr]="" # Quelle ist ein FTP
target[$nr]="${mount[$nr]:-$MOUNT}/mnt/NAS_DS1621/Backup_FHEM/Synology-1621-Backup-FHEM"
log[$nr]="${target[$nr]}/$(date +%F)_${title[$nr]}.log"
exfrom[$nr]="$(mktemp "${TMPDIR:-/tmp}/tmp.rsync.XXXX")"
rsync_opt[$nr]=""
cat > "${exfrom[$nr]}" <<_EOF_
dev/
lost+found/
mnt/
proc/
sys/
tmp/
var/tmp/
video/
_EOF_

Evtl. muss ich etwas auf der DS anders machen als auf meinen Qnaps. Aber ich weiß nicht mehr was, hatte einige Dinge schon probiert aber kein Erfolg. betrifft User und Gruppen Rechte.
Aber diese habe ich auf dem Qnap auch nicht gehabt und es funktionierte alles bestens.

Verzeichnisse sind auf der Synology angelegtals oberstes Sicherung--> Backup_FHEM
IP der Synology ist die 10.0.0.33
Ich möchte das Verzeichnis welches ich auf der Synology genauso angelegt habe wie auf meinen Qnap in meine Fhem Installation mounten dabei bekomme ich aber folgenden Fehler:
Evtl. muss ich da Rechte bearbeiten, aber mir ist nicht ganz klar welche..?

root@fhem-server:~# mount 10.0.0.33:/Sicherung/Backup_FHEM /mnt/NAS_DS1621/Backup_FHEM
mount.nfs: access denied by server while mounting 10.0.0.33:/Sicherung/Backup_FHEM
Zum Vergrößern anklicken....
 
Ich kann dazu auch nicht viel sagen. Das es mit den Rechten zu tun haben muss scheint klar zu sein:
Sie müssen registriert sein, um Links zu sehen.

Versuch mal die Rechte auf dem Server (/Sicherung) auf 755 zu setzen. Ansonsten eventuell auch wie im obigen Beitrag mal nfsv4 verwenden oder mit der Option -o v3 Wovon aber abgeraten wird...
 
Die Rechte sind schon von Synology her auf 777 und nfsv4 habe ich eingestellt, aber geht trotzdem nicht.
 
Das Problem hat ja nichts mit dem Skript direkt zu tun. Ich weiss dazu leider auch nicht mehr. Du solltest eventuel mal in einem Synology-Forum nachfragen. Das Problem scheint nicht so selten zu sein:
Sie müssen registriert sein, um Links zu sehen.
 
Zuletzt bearbeitet:
Hallo guten Tag, ich habe es klären können, das Script braucht auf der Synology ein paar mehr Angaben.
Es lag eigentlich nur am Mountpoint
Für einen manuellen mount auf meiner DS1621+:
mount -t nfs -o rw,soft,timeo=50,retrans=5,rsize=32768,wsize=32768,tcp,nolock 10.0.0.33:/volume1/Sicherung/Backup_FHEM /mnt/NAS_DS1621/Backup_FHEM

in meiner auto.mount
Synology-1621-Backup-FHEM -fstype=nfs,rw,retry=0 10.0.0.33:/Sicherung/Backup_FHEM

bei deinem Script ist alles so geblieben bei der Angabe für das target
target[$nr]="${mount[$nr]:-$MOUNT}/mnt/NAS_DS1621/Backup_FHEM/Synology-1621-Backup-FHEM"

Vielen Dank auf diesem Wege nochmals für das Script was ich nun schon viele Jahre nutze.
Ich habe mich bisher nicht um Updates gekümmert weil ja alles gut läuft.
Bei Github gibt es ja wohl einiges neues, ist es ratsam zu wechseln und muss ich dazu sehr viel ändern, dann schaue ich mir das mal bei Gelegnheit an.
 
Zuletzt bearbeitet:
Von der grundfunktionalität ist es noch gleich. Sind halt mit der Zeit einige Anpassungen und wünsche eingeflossen. Du kannse den aktuellen Stand ja testen und falls es nicht klappt auf die Version zurückgehen, die Du jetzt hast.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Menü
Anmelden
Registrieren
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…