EX2: Backup auf USB


#1

Hallo liebe Community,

seit einiger Zeit habe ich eine EX2 und bisher auch recht zu frieden.

Hier und da könnte noch ein wenig nachgebessert werden, aber das kommt hoffentlich noch.

Ich habe allerdings eine Sorge bezüglich der Backup-Funktion:

Ist es möglich ein regelmäßiges Backup auf einem USB-Gerät zu erstellen und das am besten noch inkrementell???

Es sieht danach aus als würde es nur beim internen Backup funktionieren, was in meinen Augen überhaupt keinen Sinn macht! Raucht eine Platte ab ist das Backup futsch, es sei denn man hat zwei getrennte Volumes laufen.

Hat einer ne Idee wie sich das lösen lässt? Manuell jedes mal ein mehrere GB großes Backup machen und jedes mal aufs neue vollständig finde ich äußerst unpraktisch.

Vielen Dank!

Gruß


#2

Jap, hab das selbe Problem. Ich hab´s heute auch versucht, aber leider macht das WD Book immer einen neuen Ordner, statt nur die neu hinzugefügten Dateien zu speichern.

Ich fürchte, dass das momentan ebenso wenig funktioniert, wie ein selbstablaufendes Backup über´s LAN von LAN-HDD zum WD Book.


#3

Hi,

eigentlich wird das ab Seite 72 der Bedienungsanleitung ganz gut beschreiben. Und bei der Ex2 sind noch deutlich mehr Funktionen als bei der MyCloud.

Gruß

Lucky:wink:


#4

Tach Jung!

Danke für eure Antworten!

Das zeigt mir, dass es doch Interesse an dem Problem besteht :wink:

Die Remotebackup-Funktion habe ich auch schon entdeckt, aber leider ist das nicht die Lösung meines Problems…

Die USB-Sicherung ist leider noch sehr beschränkt, so dass dort nur Backups manuell gemacht werden können. Es ist zwar möglich einen Job zu erstellen, aber leider keinerlei Optionen diesen zu wiederholen, geschweige denn ein inkrementelles Backup zu machen.

Gestern habe ich mir nochmal die “Interne Sicherung” angeschaut, vom Prinzip will ich genau diese Funktion aber von NAS zu USB.

Kleinere Recherchen über SSH haben ergeben, dass das Backup via “rsync” gemacht wird.

Ich muss jetzt nur noch herausfinden wo man diesen Aufruf entsprechend etwas modifizieren kann…

Freue mich über Hilfe, denn in Linux bin ich unbefleckt.

Gruß


#5

NA ALSO!!! ICH HABS! :slight_smile:

Ich habe eine brauchbare Zwischenlösung für das wiederholte inkrementelle Backup gefunden!!!

Zwar nicht ganz sauber, aber trotzdem gut! :wink:

Ich habe folgendes probiert und gemacht:

Zuerst mal wollte ich wissen, wo das System die Pfade für das Backup “Interne Sicherung” speichert, das hat Stunden gedauert bis ich es gefunden habe, aber ich habe es gefunden:

/mnt/HD_a4/.systemfile/schedcfgs/

Dort werden *.xml Dateien erzeugt, in denen die scr und dsc Pfade in HEX stehen.

Also Converterangeschaltet und fröhlich die Pfade zur USB geändert…

Vorhegehn für euch:

  1. USB anschließen und einrichten, Name, nicht öffentlich, etc.

ihr dürft auf keinen Fall die .smb.xml löschen die dort erzeugt wird! Sonst weiß euer UI und Samba nicht mehr wer wie was und stellt alles auf ursprung zurück!!!

  1. einen Backupplan erstellen (Interne Sicherung)

  2. /mnt/HD_a4/.systemfile/schedcfgs/*.xml öffnen und die Pfade nach belieben ändern und speichern!

  3. im UI mal checken obs geklappt hat, aber nicht speichern

  4. zum test mal laufen lassen und top im auge behalten ob rsync mit den richtigen pfaden gestartet wird.

VIEL SPASS mit BACKUP TO USB INKREMENTELL!!! :wink:


#6

Hallo Leute,

leider funktinoert meine Lösung nicht so schön, wie ich es angepriesen habe.

Zu Anfang hat alles noch prima funktioniert, leider tuts das jetzt nicht mehr und zur Zeit habe ich keinerlei Erklärung dafür…

Das interne Backup benutzt “rsync”, was ich zu Anfang auch schön im “top” beobachten konnte. Der Job wird zwar irgendwie noch ausgeführt, nur kommt es nicht zum Aufruf von rsync, stattdessen wir jetzt nur noch "du -sb " aufgerufen…

Kann mir vielleicht irgendjemand erklären, was da passiert?

Und hat jemand eine Idee wie man nach einem Reboot des Systems ein Skript ausführen kann?

Danke

Gruß


#7

Hm ok, bei manueller ausführung und ohne Parameter q (quiet) lässt sich folgendes herausfinden:

/ # rsync --timeout=30 --job-name=loc!_BilderToUSB -aH /mnt/HD/HD_a2/Daten/Bilder/ /mnt/USB/USB2_c1/Daten/Bilder/
du: write error
dry_total_size:2
rsync: writefd_unbuffered failed to write 556 bytes to socket [sender]: Broken pipe (32)
rsync error: timeout in data send/receive (code 30) at io.c(1530) [sender=3.0.7]

#8

Moinsen,

ich habe hier auch eine MyCloud EX2 im Einsatz. Hab heute grad den Firmwareupdate 1.05.21 aufgespielt und mal beim USB Backup reingeguckt ob sich was geändert hat. Ich habe 2 Aufträge erstellt die jeweils ein Verzeichnis von der EX2 auf eine angehängte USB Platte sichern sollen (Public und Public_Archiv) Der kleine von den Beiden (5Gb, 93Verz., 509 Dateien) läuft bestens durch, der weit aus größere ( 250Gb, tausende von Ordnern und Dateien :slight_smile: ) behauptet zwar anfänglich in den Details das er ausgeführt wird, bricht dann aber nach einiger Zeit ab und es ist nicht eine Datei kopiert. Bei dem kleinen backup läuft auch schön der Balken bis 100% durch, beim Zweiten bleibt der verborgen. Eine aussagekräftige Fehlermeldung wird vermieden…

Gibts da schon einen Lösungsansatz? So macht das ja gar keinen Sinn. Einzige Möglichkeit bleibt die Daten übers Netz zu sichern aber auch irgendwie Quatsch wenn es in der EX2 vorgesehen ist. Irgendwann muß das doch mal einer mitkriegen das es nicht funktioniert, dat Ding ist doch nicht erst seit gestern auf dem Markt :frowning:

USB 2 oder 3, langes oder kurzes Kabel ist alles Wurscht…

LG

OldSmoky


#9

Hallo zusammen,

gibt es hierfür eine Lösung?
Das ist die Einzige Option, die ich im Webinterface vermisse :frowning:

LG


#10

Hallo in die Community,

ich habe in der Tat vor einiger Zeit eine brauchbare Lösung gefunden, die bei mir mittlerweile schon sehr lange läuft. Allerdings ist es für unbefleckte vielleicht nicht ganz so einfach…

Zuerst einmal müssen wir zusehen, dass wir einen Eintrag in die "crontab" bekommen. Einige werden jetzt sagen: Moment mal, die Einträge dort drin bleiben ja nicht ewig enthalten! Richtig, auch das hat mich anfangs geärgert. Das liegt daran, dass in der Crontab eine Routine regelmäßig aufgerufen wird, die die eigene Tabelle von nicht zulässigenCronjobs befreit… An sich eine nette Idee, aber blöd, wenn man gerne einen eigenen Cron erstellen möchte. Diese Sicherung seitens WD ist jedoch mit einem kleinen Trick umgehbar, denn es gibt eine Datei, in der die zulässigen Cronjob-Einträge hinterlegt sind! Dort können nun neue Crons hinzugefügt werden, was später von der Routine berücksichtigt wird und somit dauerhaft in der Crontab erhalten bleibt! Diese zulässigen Einträge könnt ihr in /usr/local/config/config.xml hinzufügen!

Dort tragt ihr im Bereich <crond> neue gültige Listeneinträge ein:
Zum einen ist dort der Listenbereich <list> in den ihr einen neuen Namenseintrag hinzufügen müsst:
<name id="">backup</name> bei id tragt eine cronologisch größere Zahl ein.
Weiterhin müsst ihr weiter unten jeden Listeneintrag nochmal näher erklären, also Zeiten hinzufügen.
<backup>
<item id="1">3``
<1>0</1>
<2>10</2>
<3>*</3>
<4>*</4>
<5>*</5>
<run>/mnt/HD/HD_a2/backupscript/backup.sh &amp;</run>
</item>
</backup>

Die Zahlen 1-5 geben die Ausführungszeit des Cronjobs an! Weitere Infos dazu findet ihr unter:
https://wiki.ubuntuusers.de/Cron/

Nachdem ihr die Einträge in der config.xml gemacht habt, solltet ihr einmal die NAS neu starten, damit es wirksam wird! Denn auch die xml wird hin und wieder neu geschrieben. Wie das alles genau funktioniert, habe ich nicht durchblickt, aber ein Neustart hilft.

Nun könnt ihr euch ein x-beliebiges Skript für das Backup schreiben und im obigen Pfad ablegen. Beispielsweise könnt ihr mit rsync ein vollständiges Backup erstellen lassen.

Mein Script ist vielleicht etwas “billig” geschrieben, dafür funktioniert es gut! Und es wird automatisch der Mount-Pfad der USB-Festplatte anhand der UID ermittelt.

Hier mein Skript

backup.sh

#!/bin/bash
clear
### Check USB-Backup Device and Mountpoint
echo -e "Find Backup by UUID...\n"
backup_uuid="xxxxxxxxxxxxxxxx" Die UUID der jeweiligen Platte bekommt ihr mit blkid heraus!
echo "UUID: "$backup_uuid
backup_dev=$(blkid -l -o device -t UUID="$backup_uuid")
echo "dev: "$backup_dev
backup_mnt=$(df -P | grep $backup_dev | awk '{print $6}')
echo "mnt: "$backup_mnt
backup_path=$backup_mnt"/Backup"
echo -e "\nBackup goes"
echo -e "From:\t\t\t\tTo:\t\t\t\tLog:"
SOURCE1="/mnt/HD/HD_a2/Daten"
TARGET1=$backup_path
LOG1="$TARGET1/LOG/$(date +%F)-Daten.txt"
echo -e $SOURCE1"\t->\t"$TARGET1"\t\t"$LOG1
BAK_DIR="$TARGET1/DelDat/$(date +%F)/"
RSY_OPT="-savPbh --delete --numeric-ids --stats"
MOUNTPOINT=$backup_mnt
### Check USB mount
if [ "$MOUNTPOINT" ]; then
MOUNTED=$(mount | fgrep "$MOUNTPOINT");
fi
### Backup if mounted
if [ -z "$MOUNTPOINT" ] || [ "$MOUNTED" ]; then
### First Backup
eval rsync $RSY_OPT --log-file=\"$LOG1\" --exclude=.* --backup-dir=\"$BAK_DIR\" $SOURCE1 \"$TARGET1\"
###
echo ""
else
echo "USB not mounted! Send Mail..."
#send_gen_mail -m message -s subject -r mail@mail.mail
fi

Wenn ihr das Script vorerst testen wollt, dann kommentiert den rsync-Befehl erstmal aus und startet das Skript in der Console! Es gibt einige Ausgaben, die hilfreich sind!

Nun viel Erfolg beim Basteln! Ich hoffe ich konnte euch etwas helfen!

Wer Verbesserungsvorschläge hat, um mein Skript zu verbessern, gerne unten einen Kommentar hinterlassen! :slight_smile:

Gruß
Stephan


#11

Hallo Stephan,
vielen Dank dafür, ich habe es gleich getestet.
Leider wird bei mir die config.xml nach einem Neustart wieder zurückgesetzt und meine gesetzten Einträge innerhalb der (EDIT config.xml, nicht Backup.sh) fliegen wieder raus, sowohl “oben” als auch “unten”.
Ich bin auf Firmware 2.31.149, läuft es bei dir damit?


#12

Hallo Marc,

ich habe eine MyCloud EX2 und mir zeigt mein System an, dass die Firmware 2.11.178 die aktuellste Version derzeit ist. Kann es sein, dass du ein anderes Modell hast?
Die Methode, zuerst die /usr/local/config/config.xml zu ändern und sofort danach einen Neustart zu machen, funktioniert bei mir sehr gut, so dass die gemachten Einstellungen erhalten bleiben!
Die gemachten Einträge beziehen sich allerdings auf die config.xml und nicht auf die backup.sh, das klingt nach deinem Satz oben etwas anders… Die backup.sh soll nur durch den neu eingetragenen Cronjob aufgerufen werden! Was du innerhalb des backup-scriptes machst, steht auf einem anderen Blatt…

VG
Stephan

Edit:
Ich habe soeben nochmal nach allen config.xml-Dateien gesucht und in Summe drei gefunden! Zwei sind scheinbar clone und eine ist ein default. Vielleicht hilft es, wenn du die beiden Clone gemeinsam editierst und danach sofort einen Neustart machst. Vielleicht schützen sich die Dateien gegenseitig gegen Manipulation?

root # find / -name config.xml
/etc/NAS_CFG/config.xml
/usr/local/modules/default/config.xml
/usr/local/config/config.xml

Versuch macht klug! :wink:


#13

Hallo Stephan,

ich habe eine MyCloud EX2 Ultra, vielleicht kommt daher der andere Firmware-Stand.
Das mit der config.xml ist mir klar. Allerdings wird diese auf den Ursprung zurückgesetzt, sobald ich die NAS neu starte. Das mit der backup.sh ist keine Herausforderung, diese bleibt immer bestehen.
Ich habe soeben deinen EDIT gesehen, vielen Dank für den Hinweis, dem werde ich nachgehen und mich nochmal melden.

EDIT:
Bei mir (EX2 Ultra FW 2.31.149) wird eine Datei mehr gefunden.

root@MyCloudEX2Ultra root # find / -name config.xml
/usr/local/modules/default/config.xml
/usr/local/modules/firefly/firefly/share/mt-daapd/admin-root/config.xml (ist irgend etwas von iTunes)
/usr/local/config/config.xml
/etc/NAS_CFG/config.xml

In /usr/local/modules/default/config.xml steht fast genau das Selbe wie in /usr/local/config/config.xml. Im < crond > stehen allerdings nur 6 Einträge und die IP-Konfiguration sieht nach der wirklichen Default-Konfiguration aus (anderes Netz). Diese Datei habe ich unberührt gelassen.

In /etc/NAS_CFG/config.xml schaut alles exakt gleich wie in /usr/local/config/config.xml aus. Ich habe diese beiden Dateien auf den Selben Inhalt angepasst.

Ein Hinweis: Im < list > Bereich habe ich die nächst höhere ID genommen, dem Schema nach. Im < cron > Bereich hatte bei mir jeder Eintrag die ID=1, das habe ich so auch für den neu Gesetzten genommen.

Nach dem sofortigen Neustart blieb mein Eintrag dieses Mal bestehen, allerdings hat das System den Eintrag von Position und ID 11 an die Position 7 geschoben und die ID 7 verpasst. Alle weiteren Einträge wurden bezüglich der ID um 1 erhöht. (quasi zwischen eingeschoben).

Vielen Dank Stephan für den Hinweis, das mit dem Abgleich zweier config.xml’s hat sich also bestätigt und war die Lösung!

Viele Grüße
Marc