Linux, bitte um Hilfe, bzgl. rsync

[Frank Norbert Stein *. (franknstein)]

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.

[Herr Müller-Lüdenscheidt (Gast)]

&& date -R >$filename

anhängen

[Frank Norbert Stein *. (franknstein)]

Klasse, dankeschön, nur wie jetzt anhängen?

So?
0 2 *(Stern) *(Stern) *(Stern)  rsync -arz --delete
/media/pi/HD1/Verzeichnis/  /media/pi/HD2/Verzeichnis/&& date -R 
>$filename

[Felix (Gast)]

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.

[Hunsbuckel (Gast)]

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/

[Daniel A. (daniel-a)]

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.

[Frank Norbert Stein *. (franknstein)]

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?

[T.roll (Gast)]

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

[Frank Norbert Stein *. (franknstein)]

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.

[T.roll (Gast)]

Wie die anderen Parameter einfach nach "rsync" dazu schreiben.

[T.roll (Gast)]

Natürlich ohne den Kommentar (#...).

[Stefan L. (timpi)]

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.

[Axel S. (a-za-z0-9)]

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:

~ $ls -l /etc/cron.daily/
total 84
-rwxr-xr-x 1 root root  314 Dec  5  2008 10_aptitude*
-rwxr-xr-x 1 root root 2534 Aug 13  2008 10_cyrus22*
-rwxr-xr-x 1 root root 3349 Sep 28  2008 10_standard*
-rwxr-xr-x 1 root root   89 Oct  8  2008 18_logrotate*
-rwxr-xr-x 1 root root  335 Dec 14 08:53 19_sync2zeta3*
-rwxr-xr-x 1 root root  455 Nov  7  2016 20_mysqlbackup*
-rwxr-xr-x 1 root root  448 Nov  7  2016 20_svnbackup*
-rwxr-xr-x 1 root root 1392 Nov  7  2016 30_storebackup*
-rwxr-xr-x 1 root root 7482 Apr 20  2009 80_apt*
-rwxr-xr-x 1 root root 1658 Dec 28  2008 80_leafnode*
-rwxr-xr-x 1 root root 1154 May 11  2009 80_ntp*
-rwxr-xr-x 1 root root  633 Jul 14  2009 99_apache2*
...

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:

~ $cat /etc/cron.daily/19_sync2zeta3 
#! /bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin

set -e
set -u

DIRS="/export/PVR"

for DIR in $DIRS
do
  #echo "synching $DIR ..."
  rsync -aqSx --delete $DIR/ zeta3:$DIR/
done

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.

[Frank Norbert Stein *. (franknstein)]

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

[snappie (Gast)]

rsnapshot wurde noch nicht erwähnt!

Hilft besonders gut wen man erst nach x Backups feststellt dass was 
schief gelaufen ist..

[Axel S. (a-za-z0-9)]

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.

[Rolf M. (rmagnus)]

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.

[Uwe B. (boerge)]

Stefan L. schrieb:
> dann schau Dir auch mal
> storeBackup (https://www.nongnu.org/storebackup/de/) an.

...wenn storeBackup erwähnt wird, dann bringe ich mal noch rdiff.backup 
(https://www.nongnu.org/rdiff-backup/) mit ins Spiel, mit dem ich einige 
meiner Rechner im Home-Netzwerk sichere... Auch hier wird eine 
Versionierung mehrerer Backups durchgeführt

[Egon N. (egon2321)]

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.

[Md M. (Firma: Potilatormanufaktur) (mdma)]

Egon N. schrieb:
> Dann ist es aber zu prüfen ob keine E-Mail kommt.

Besser als andersrum.

[Stefan M. (kosh604)]

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!):

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)

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.

[bofh (Gast)]

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.

[Bernd K. (prof7bit)]

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!

#!/usr/bin/python3

import os
import time

INCLUDE = [
    '/home/bernd',
    '/dieser/ordner',
    '/jener/ordner',
    '/media/windows'
]

DISK_UUID = "64f281c4-5799-4608-88e2-cea581f515d8"
MOUNT_POINT = "/mnt/backup"


def sh(cmd):
    print('$ ' + cmd)
    os.system(cmd)

def mount():
    sh("mkdir -p {}".format(MOUNT_POINT))
    sh("mount UUID='{}' {} -o compress-force=zlib,noatime".format(DISK_UUID, MOUNT_POINT))
    
def umount():
    sh("umount {}".format(MOUNT_POINT))

def get_current_backup_path():
    return os.path.join(MOUNT_POINT, 'current')

def create_snapshot():
    snap = os.path.join(MOUNT_POINT, time.strftime("snapshot-%Y-%m-%d-%H-%M-%S"))
    sh("btrfs subvolume snapshot -r {} {}".format(get_current_backup_path(), snap))
    sh("ls -la {}".format(MOUNT_POINT))

def get_include_exclude_list():
    l = ""
    for directory in INCLUDE:
        l += '--include="{}" '.format(directory)
        l += '--include="{}/**" '.format(directory)
    l += '--exclude="*"'
    return l

def rsync():
    inc = get_include_exclude_list()
    dest = get_current_backup_path()
    if not os.path.exists(dest):
        sh('btrfs subvolume create {}'.format(dest))
    sh('rsync --info=progress2 --delete -a -m {} / {}'.format(inc, dest))

def check_root():
    if os.geteuid() != 0:
        sh('sudo {}'.format(__file__))
        exit()

def main():
    check_root()
    mount()
    rsync()
    create_snapshot()
    umount()
    
if __name__ == '__main__':
    main()

So sieht das dann aus:

$ ls -la /mnt/backup
insgesamt 20
drwxr-xr-x  1 root root  350 Mär 28 20:25 .
drwxr-xr-x 15 root root 4096 Mär  3 16:16 ..
drwxr-xr-x  1 root root   28 Mär 25 18:10 current
drwxr-xr-x  1 root root   28 Dez 16 17:05 snapshot-2018-01-22-23-20-55
drwxr-xr-x  1 root root   28 Jan 22 23:34 snapshot-2018-01-23-00-30-36
drwxr-xr-x  1 root root   28 Feb 23 17:52 snapshot-2018-03-11-18-35-29
drwxr-xr-x  1 root root   28 Mär 15 17:29 snapshot-2018-03-24-18-18-29
drwxr-xr-x  1 root root   28 Mär 15 17:29 snapshot-2018-03-24-18-26-07
drwxr-xr-x  1 root root   28 Mär 25 18:10 snapshot-2018-03-28-20-25-04

[Stefan M. (kosh604)]

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.

[Daniel A. (daniel-a)]

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.

[butterFS (Gast)]

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.

[Axel S. (a-za-z0-9)]

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.

[Frank Norbert Stein *. (franknstein)]

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.

[Md M. (Firma: Potilatormanufaktur) (mdma)]

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)

[Sheeva P. (sheevaplug)]

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)

;-)

[Md M. (Firma: Potilatormanufaktur) (mdma)]

Sheeva P. schrieb:
> date -I

Auch mein favorite

[Egon N. (egon2321)]

Backup:
https://www.borgbackup.org/
https://www.duplicati.com/

Sync:
https://github.com/axkibe/lsyncd
https://wiki.archlinux.org/index.php/anything-sync-daemon

Gibt da so einiges mit mehr Features, oftmals gibt es so viele Lösungen 
dass man erst mal ewig vergleichen muss. ;)

[FDay -1 (Gast)]

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

[Frank Norbert Stein *. (franknstein)]

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 (Gast)]

cron und '%':

The entire command portion of the line, up to a newline or % character..

[Md M. (Firma: Potilatormanufaktur) (mdma)]

zeitgeist schrieb:
> cron und '%'

Aha. Guter Hinweis, ich wär demnächst auch drüber gestolpert.

[Stefan M. (kosh604)]

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:

0 2  * * *  rsync -a --delete /media/pi/HD1/Verzeichnis/ /media/pi/HD2/Verzeichnis/ && touch /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date -I)