Hallo und guten Abend,
ich versuche mich gerade ein wenig in Linux einzuarbeiten, obwohl ich
von Linux überhaupt (noch) keine Ahnung habe.
Vor mir liegt ein Raspberry Pi 3B+ mit zwei USB-Festplatten (HD1+HD2)
und der soll mir als kleines NAS dienen. Als OS nutze ich Rasbian
Stretch. Zugriff hierauf mit div. Rechnern funktioniert wunderbar per
SSH.
Soll heissen, der Raspi soll z.B. täglich den Inhalt von HD1 auf HD2
sichern, also ein Spiegelbild anfertigen.
Hierzu hatte ich den offenbar sehr mächtigen Befehl "rsync" gefunden und
diesen in "crontab -e" eingebunden.
Mein Gewurschtel in crontab:
0 2 *(Stern) *(Stern) *(Stern) rsync -arz --delete
/media/pi/HD1/Verzeichnis/ /media/pi/HD2/Verzeichnis/ # Spiegeln
tägl. 2 Uhr HD1 auf HD2
Das funktioniert wunderbar, aber:
Ich würde gerne noch irgendwie das Datum der Spiegelung mitspeichern, um
immer sehen zu können, ob auch immer aktuell gespiegelt wurde.
Allerdings muss das Erstellungsdatum der einzelnen Dateien dabei
unbedingt erhalten bleiben.
Optimal wäre, wenn z.B. eine (leere) Datei namens "letzte Sicherung am
xx.xx.xxxx" (Datum der Spiegelung) auf HD2 immer wieder überschrieben
werden könnte.
Aber das bekomme ich nicht.
Habt ihr vielleicht einen Tipp?
Danke,
Frank
P.S. Nach meinem ersten Rumschnüffeln in Linux ärgere ich mich heute, so
viel Zeit mit Windows verschwendet zu haben. Linux bietet offenbar ein
offenes und dabei auch unendlich flexiebles System.
Oder eine Textdatei auf HD1 erstellen wenn noch nicht vorhanden und dann
vor jeder Sicherung das aktuelle Datum + Uhrzeit anhängen z. B. per
echo date >> textdatei.txt
Danach die Sicherung laufen lassen und diese Datei dabei mitsichern
lassen.
Mit den beiden ampersand verknüpft Du die Befehle so, dass der zweite
Befehl erst nach Beendigung des ersten Sbefehls ausgeführt wird —- die
musst also ein blank(Leerzeichen ) vor && setzen
Schau mal hier:
https://wiki.ubuntuusers.de/Shell/Operatoren/
Ich lasse mir nach jedem Backup ein Mail senden mit Ausgabe des Backup
scripts, datum, und freiem Festplattenspeicher. Fällt dann schneller
auf, wenn etwas schief geht.
Und ist nur 1 Backup wirklich genug? Wenn man erst am nächsten tag
realisiert, dass man das falsche File überschrieben hat, hat man pech
gehabt. Ich kann inkrementelle hardlink backups empfehlen, die nehmen
fast keinen Platz weg. Falls es aber weniger ums Backup und mehr um die
Redundanz geht kann ich Raid 1 mittels Linux Software Raid empfehlen,
ist aber beim pi nicht ideal.
rsync bietet auch die schöne Funktion des Logging.
--log-file=FILE
Mit ein bisschen Shellzauber kannst du den Dateinamen auch als aktuelles
Datum gestalten (date-Funktion).
--log-file=`date +%Y-%m-%d` #jahr-monat-tag
T.roll schrieb:> rsync bietet auch die schöne Funktion des Logging.
Dankeschön, nur meine Kenntnisse sind einfach noch zu gering.
Könntest du mir vielleicht den kompletten Eintrag in crontab schreiben?
Dankeschön.
Frank Norbert S. schrieb:> Könntest du mir vielleicht den kompletten Eintrag in crontab schreiben?
Schau mal in die /etc/crontab (oder /etc/anacrontab). Dort sind die
Einträge für die stündlich, täglich, wöchentliche und monatlich
auszuführenden Aktionen.
Du kannst auch ein Shellscript in /etc/cron.daily anlegen ("chmod +x"
nich' vergessen), dass wird dann täglich ausgeführt.
timpi.
PS: Wenn Du das von daniel-a vorgeschlagene Verfahren nutzen möchtest
(mit Hardlinks und Sichern über längere Zeit), dann schau Dir auch mal
storeBackup (https://www.nongnu.org/storebackup/de/) an.
Frank Norbert S. schrieb:> Könntest du mir vielleicht den kompletten Eintrag in crontab schreiben?
Wenn man mehr machen will, als einfach nur ein Kommando auszuführen,
legt man typischerweise ein Shellskript an, wo man alle Kommandos
reinschreibt und läßt cron dann dieses Shellskript ausführen. Wenn man
nicht eine genaue Uhrzeit einhalten muß, sondern einen Job einfach nur
einmal am Tag ausgeführt haben will, bietet es sich an, das Shellskript
nach /etc/cron.daily zu tun.
Z.B. sieht das auf einer Maschine hier so aus:
1
~ $ls -l /etc/cron.daily/
2
total 84
3
-rwxr-xr-x 1 root root 314 Dec 5 2008 10_aptitude*
4
-rwxr-xr-x 1 root root 2534 Aug 13 2008 10_cyrus22*
Dabei sind 19_sync2zeta3, 20_mysqlbackup, 20_svnbackup und
30_storebackup jeweils Backup-Jobs. Durch die speziele Namensgebung
werden sie in dieser Reihenfolge ausgeführt. 19_sync2zeta3 tut in etwa
das gleiche, wie dein Cronjob:
1
~ $cat /etc/cron.daily/19_sync2zeta3
2
#! /bin/bash
3
4
PATH=/bin:/sbin:/usr/bin:/usr/sbin
5
6
set -e
7
set -u
8
9
DIRS="/export/PVR"
10
11
for DIR in $DIRS
12
do
13
#echo "synching $DIR ..."
14
rsync -aqSx --delete $DIR/ zeta3:$DIR/
15
done
16
17
exit 0
hier wird eine Anzahl Directories (im Moment nur noch eins, waren früher
mal mehr) auf einen anderen Rechner gesynct. Wenn man in der Zeile mit
"#echo" das "#" entfernt (mit ist es ein Kommentar) dann schickt cron
jedes Mal eine Email mit den Ausgaben von echo.
Ich danke euch für eure Bemühungen, klasse..!
Nur, ich bin inzwischen ein alter Zausel mit fast 70 Umdrehungen auf der
Lebensuhr und es fällt mir wirklich sehr schwer eure Tipps praktisch
umzusetzen. Ich bin mit der Röhrentechnik (wer kennt dies noch?)
grossgeworden.
Deswegen hatte ich nach einem kompletten Eintrag in "rsync" gefragt, um
mein Vorhaben auch ohne Spezialkenntnisse realisieren zu können.
Nochmals danke,
Frank
Ach ja, das hätte ich oben noch erwähnen sollen. Rsync ist ganz nett,
wenn es nur um das Synchronisieren geht. Für Backups will man lieber
mehrere Generationen vorhalten. Sonst kann es schnell passieren, daß
ein kaputtes (kaputt editiertes?) File auch im Backup nur noch in der
kaputten Form vorliegt. Ich verwende hier storeBackup.
Auf der Zielplatte sieht jedes Backup wie eine komplette Kopie des
Originals aus. Allerdings werden identische Files aus älteren Backups
nicht neu kopiert, sondern sind nur ein Hardlink auf die jeweils ältere
Version. Durch diesen Trick kann man problemlos 100 Generationen Backup
vorhalten und braucht dafür nicht 100x so viel Speicher, sondern nur
vielleicht 1.01x so viel (wenn es wenig Änderungen gibt). Außerdem
komprimiert storeBackup auf Wunsch auch und kümmert sich um Eigentümer,
Timestamps und nicht-Dateien (Symlinks, Hardlinks, device nodes, fifos
etc.)
Alles in allem kann ich es nur empfehlen. Hat mir schon mehr als einmal
aus der Patsche geholfen.
Frank Norbert S. schrieb:> Vor mir liegt ein Raspberry Pi 3B+ mit zwei USB-Festplatten (HD1+HD2)> und der soll mir als kleines NAS dienen.
Gerade der ist als NAS nicht sonderlich gut geeignet, weil sich die
beiden Festplatten mit dem Ethernet einen USB2-Port teilen. Dadurch wird
das ganze ziemlich langsam.
Hunsbuckel schrieb:> Mit den beiden ampersand verknüpft Du die Befehle so, dass der zweite> Befehl erst nach Beendigung des ersten Sbefehls ausgeführt wird
Dafür würde auch ein Semikolon reichen. Das && sorgt zusätzlich dafür,
dass der zweite Befehl nur dann ausgeführt wird, wenn der erste auch
erfolgreich war.
Daniel A. schrieb:> Ich lasse mir nach jedem Backup ein Mail senden mit Ausgabe des Backup> scripts, datum, und freiem Festplattenspeicher. Fällt dann schneller> auf, wenn etwas schief geht.
Dann ist es aber zu prüfen ob keine E-Mail kommt.
Hallo Frank,
du hast vorgeschlagen auf der Zielfestplatte eine Datei mit
entsprechendem Namen anzulegen. Wenn es für dich OK ist, wenn diese
Datei im Verzeichnis der Sicherung angelegt wird, und nicht eine Ebene
darüber im Wurzelverzeichnis der Platte, dann würde ich folgende Lösung
vorschlagen (alles in einer Zeile!):
Dadurch wird automatisch eine solche Datei angelegt, eine vorherige
würde durch den rsync Befehl auch wieder gelöscht und so hast du immer
genau eine Datei mit dem Datum der letzten Sicherung. Ich habe mir
erlaubt die zwei Parameter -r und -z wegzulassen, da sie hier keinen
Sinn ergeben (-r wird bereits durch -a abgedeckt, und eine Kompression
mit -z ist nur bei übertragung über ein Netzwerk sinnvoll).
Ich hoffe das hilft dir ein wenig weiter.
Axel S. schrieb:> Ach ja, das hätte ich oben noch erwähnen sollen. Rsync ist ganz nett,> wenn es nur um das Synchronisieren geht. Für Backups will man lieber> mehrere Generationen vorhalten. Sonst kann es schnell passieren, daß> ein kaputtes (kaputt editiertes?) File auch im Backup nur noch in der> kaputten Form vorliegt. Ich verwende hier storeBackup.
Na und? Dann sichert man halt nicht nach /media/pi/HD2/Verzeichnis/
sondern nach /media/pi/HD2/$FOO/Verzeichnis/, wobei man $FOO entweder
auf den Wochentag (7 Tage Rotation) oder Monatstag (28-31 Tage Rotation)
setzt. Jahrestag geht natürlich auch.
Oder, je nach Größe kann man $FOO auch auf YYYY/MM/DD setzen, dann hat
man die solange bis man manuell aufräumen muß.
Weiterhin kennt rsync auch ein Backupdir: dorthin werden Dateien
verschoben die gelöscht/aktualisiert werden. Damit kann man sowas wie
ein umgekehrt differentielles Backup machen.
Axel S. schrieb:> Allerdings werden identische Files aus älteren Backups> nicht neu kopiert, sondern sind nur ein Hardlink auf die jeweils ältere> Version.
Kann man auch machen, wenn man Vortagsverzeichnis mit cp kopiert (kann
Hardlinks).
Axel S. schrieb:> Außerdem> komprimiert storeBackup auf Wunsch auch und kümmert sich um Eigentümer,> Timestamps und nicht-Dateien (Symlinks, Hardlinks, device nodes, fifos> etc.)
Ich würde niemals empfehlen ein Backup zu komprimieren. Im Worst-Case
hat das Archiv einen Schaden und dann steht man dumm da. Und den Rest
macht rsync auch mit den richtigen Optionen.
Eine Alternative wäre noch die Backup-Platte mit btrfs zu formatieren,
dann kann man einfach nach dem Kopieren einen Snapshot mit Datum machen.
bei jedem folgenden Backup werden nur geänderte Dateien
überschrieben/hinzugefügt/gelöscht und man macht nach jedem Backup
anschließend wieder einen Snapshot. Jeder Snapshot kostet immer nur
soviel Speicher wie Dateien geändert wurden.
Außerdem kann btrfs transparent komprimieren.
Das ist kostet weniger Plattenplatz als eine Hardlink-Farm (mit
Kompression sogar sehr viel weniger), ist genauso zu handhaben (jeder
Snapshot sieht aus wie ein Ordner in dem sich alles so befindet wie es
zum Zeitpunkt des Backups war, direkt zugreifbar aus dem Dateimanager
ohne Zusatztools) und es geht ungefähr doppelt so schnell wie die
hardlink Methode!
Wow, ihr mutet dem OP ja schon ganz schön was zu, als Linux Neuling
versteht man dabei doch nur noch Bahnhof.
Nichtsdestotrotz begrüße ich die Erwähnung dieser ganzen Methoden, ich
erfahre gerne von anderen Backupstrategien.
Und Bernd: YMMD, eigenes Backupskript, bisher wohl die komplexeste
Lösung. Auch wenn ich kein btrfs fahre so mache ich das auch gerne so.
Frank Norbert S. schrieb:> Daniel A. schrieb:>> Ich lasse mir nach jedem Backup ein Mail senden>> Danke, wunderbar....> Wenn ich nur wüsste, wie ich so etwas realisieren könnte?
Zuerst müsste man ein Programm zum Senden der Mails einrichten, z.B.
ssmtp:
https://wiki.archlinux.org/index.php/SSMTP
Ich würde es aber nicht so konfigurieren, es ist keine gute Idee einem
Gerät das verschicken von Mails zu ermöglichen, wenn dies nicht absolut
notwendig ist. Ich habe einen eigenen Mailserver, der Mails an mich aus
dem eigenen Netz annimmt, aber es diesen nicht ermöglicht Mails nach
draussen zu senden.
Man könnte danach noch eine andere Zieladresse in cron einstellen:
https://www.cyberciti.biz/faq/linux-unix-crontab-change-mailto-settings/Egon N. schrieb:> Dann ist es aber zu prüfen ob keine E-Mail kommt.
Ja, ich weiss. Ich bin nur noch nicht dazu gekommen, für alles
monitoring auf meinem Server einzurichten, fürs erste ist das aber gut
genug.
btrfs snapshot scheint bei vielen kleinen Dateien schneller zu sein als
rsync (auf HDDs).
Das btrfs send/receive taugt wenn man seien allerwichtigsten
Katzenbilder etwas entfernt sichern will..
Nach einem wöchentlichem 'btrfs scrub' kann man besonders gut schlafen
;-)
Gute Nacht.
bofh schrieb:> Axel S. schrieb:>> Ach ja, das hätte ich oben noch erwähnen sollen. Rsync ist ganz nett,>> wenn es nur um das Synchronisieren geht. Für Backups will man lieber>> mehrere Generationen vorhalten. Sonst kann es schnell passieren, daß>> ein kaputtes (kaputt editiertes?) File auch im Backup nur noch in der>> kaputten Form vorliegt. Ich verwende hier storeBackup.>> Na und? Dann sichert man halt nicht nach /media/pi/HD2/Verzeichnis/> sondern nach /media/pi/HD2/$FOO/Verzeichnis/, wobei man $FOO entweder> auf den Wochentag (7 Tage Rotation) oder Monatstag (28-31 Tage Rotation)> setzt. Jahrestag geht natürlich auch.
Das ist nicht das gleiche.
> Oder, je nach Größe kann man $FOO auch auf YYYY/MM/DD setzen, dann hat> man die solange bis man manuell aufräumen muß.
Auch da hat storebackup ausgefeilte Regeln, nach denen es (recht
intelligent IMHO) alte Backups verwirft. Bei mir bspw. "behalte alle
Backups der letzten 30 Tage", "außerdem das erste Backup jeder Woche für
die letzten 360 Tage" und "maximal 99 Backups total".
>> Allerdings werden identische Files aus älteren Backups>> nicht neu kopiert, sondern sind nur ein Hardlink auf die jeweils ältere>> Version.>> Kann man auch machen, wenn man Vortagsverzeichnis mit cp kopiert (kann> Hardlinks).
Wie gesagt: das ist nicht das gleiche. Wenn storeBackup eine Datei
bereits in einem anderen Backup hat - und das muß nicht nur ein Backup
der gleichen Quelle sein, sondern kann im Prinzip jedes andere vorherige
Backup sein - dann kopiert es die Datei nicht auf den Backupdatenträger,
sondern legt dort einen Hardlink auf die alte Version ab.
Wenn du bspw. 10 RasPi's in deinem Heimnetzwerk hast, auf denen überall
das gleiche Raspian läuft und die mit storeBackup auf das gleiche NAS
sicherst, dann liegt dort am Ende nur eine Kopie von Raspian und für die
9 anderen sind es nur noch Hardlinks. Bis auf die Dateien natürlich, die
sich unterscheiden.
Die derartig deduplizierten Dateien müssen übrigens weder gleich heißen
noch den gleichen Eigentümer oder die gleichen Timestamps haben.
>> Außerdem komprimiert storeBackup auf Wunsch> Ich würde niemals empfehlen ein Backup zu komprimieren. Im Worst-Case> hat das Archiv einen Schaden und dann steht man dumm da.
storeBackup komprimiert einzelne Files. Ob ein komprimiertes File
beschädigt ist oder ein unkomprimiertes, ist im Zweifelsfall gleich
schlecht. Außerdem: wenn dein Backup-Speichermedium weniger zuverlässig
ist, als das medium von dem du die backups machst, dann hast du ganz
andere Probleme, als die Auswahl einer passenden Backup-Software.
Ich könnte deine Argumente wesentlich ernster nehmen, wenn du dir die
von dir schlecht geredete Software wenigstens mal angesehen hättest. So
hast du dich (mal wieder) nur als übler Schwätzer entpuppt.
Hallo
und einen Superdank an Stefan M. (kosh604), der mich und mein Problem
richtig einschätzte. Natürlich bedanke ich mich auch für alle anderen
Antworten, allerdings waren sie für mich leider gar nicht hilfreich,
bzw. gingen auch an meiner Frage vorbei.
Mit seinen Worten: "Wow, ihr mutet dem OP ja schon ganz schön was zu,
als Linux Neuling versteht man dabei doch nur noch Bahnhof." hatte
Stefan absolut Recht und genau so ist es mir bei vielen Einträgen mit
vielen Bahnhöfen ergangen.
Das Einzige, das ich kapiert hatte war Stefans Vorschlag. Seine Zeile:
"0 2 * rsync -a --delete /media/pi/HD1/Verzeichnis/
/media/pi/HD2/Verzeichnis/ && touch
/media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date %d.%m.%Y)"
half mir zielführend weiter. Die Befehle "&&" und "touch" kannte ich als
Neuling gar nicht, nun weiss ich aber ein wenig hierüber Bescheid.
Allerdings erzeugte diese Zeile eine leere Datei (letzte_Sich...usw.)
nur dann, wenn ich die Zeichenkette "_$(date %d.%m.%Y)" am Ende
entfernte. Mit diesen Variablen wurde gar keine Datei erzeugt. **
Das ist aber nicht so tragisch, denn die Datei hat ja selbst ein
Erstellungsdatum.
Nochmals ein Dankeschön von
Frank
**) Korrektur: Sehe eben, dass mit der Zeichenkette doch die leere Datei
geschrieben wird, allerdings ohne Anhang der Daten an den Dateinamen.
Stefan M. schrieb:> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date +%d.%m.%Y)Frank Norbert S. schrieb:> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date %d.%m.%Y)
Md M. schrieb:> Stefan M. schrieb:>> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date +%d.%m.%Y)>> Frank Norbert S. schrieb:>> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date %d.%m.%Y)
/media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date -I)
;-)
Frank Norbert S. schrieb:> Das ist aber nicht so tragisch, denn die Datei hat ja selbst ein> Erstellungsdatum.>
Kleine Falle, es gibt kein Erstellungsdatum ;)
Jdf. keines an das man ohne Tricks herankommt ('crtime' bei ext4)
---
Was du als Erstellungsdatum bezeichnest schimpft sich die
Modify Time (mtime).
Bei einem backup mit rsync möchtest du evtl.
-t, --times preserve modification times
setzen, damit diese der Zeit des Originals entspricht.
Das kann bei vergleichen helfen, je nachdem was man vorhat.
Ich bervorzuge 1:1 kopien plus eben eine Liste aus der hervorgeht was
wann wohin kopiert wurde.
Hier hat sich jmd. die Mühe gemacht das in dt. Sprache zu erläutern.
http://linux-club.de/wiki/opensuse/Zeitstempel_von_Dateien
Md M. schrieb:> Stefan M. schrieb:>> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date +%d.%m.%Y)>> Frank Norbert S. schrieb:>> /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date %d.%m.%Y)
Vermutlich ist hier das fehlende Pluszeichen vor %d gemeint, aber dieses
verschwand vermutl. durch die Forensoftware. Ich hatte diese
Befehlszeile von
Stefan durch Markieren mit der Maus kopiert und danach in meinem Text
eingefügt, wonach das Pluszeichen weg war, genau so wie zwei wiederholte
Sternchen am Anfang der Zeile. In meinem crontab ist die Zeile komplett
eingetragen.
Tschüss
Frank
zeitgeist schrieb:> cron und '%':
Oh, wieder was gelernt, vielen Dank für diesen Hinweis!
Frank Norbert S. schrieb:> Vermutlich ist hier das fehlende Pluszeichen vor %d gemeint, aber dieses> verschwand vermutl. durch die Forensoftware.
Das dachte ich auch zuerst, aber es liegt an den Prozentzeichen welche
für cron eine besondere Bedeutung haben. Hier wurde aber bereits eine
andere Möglichkeit genannt, der -I Parameter für date. Allerdings dreht
dieser die Reihenfolge um zu Jahr-Monat-Tag. Damit sähe deine crontab
Zeile nun so aus:
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang