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.
:
Bearbeitet durch User
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
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.
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?
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.
Wie die anderen Parameter einfach nach "rsync" dazu schreiben.
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* |
5 | -rwxr-xr-x 1 root root 3349 Sep 28 2008 10_standard* |
6 | -rwxr-xr-x 1 root root 89 Oct 8 2008 18_logrotate* |
7 | -rwxr-xr-x 1 root root 335 Dec 14 08:53 19_sync2zeta3* |
8 | -rwxr-xr-x 1 root root 455 Nov 7 2016 20_mysqlbackup* |
9 | -rwxr-xr-x 1 root root 448 Nov 7 2016 20_svnbackup* |
10 | -rwxr-xr-x 1 root root 1392 Nov 7 2016 30_storebackup* |
11 | -rwxr-xr-x 1 root root 7482 Apr 20 2009 80_apt* |
12 | -rwxr-xr-x 1 root root 1658 Dec 28 2008 80_leafnode* |
13 | -rwxr-xr-x 1 root root 1154 May 11 2009 80_ntp* |
14 | -rwxr-xr-x 1 root root 633 Jul 14 2009 99_apache2* |
15 | ... |
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
rsnapshot wurde noch nicht erwähnt! Hilft besonders gut wen man erst nach x Backups feststellt dass was schief gelaufen ist..
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.
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
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!):
1 | 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.
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!
1 | #!/usr/bin/python3
|
2 | |
3 | import os |
4 | import time |
5 | |
6 | INCLUDE = [ |
7 | '/home/bernd', |
8 | '/dieser/ordner', |
9 | '/jener/ordner', |
10 | '/media/windows' |
11 | ]
|
12 | |
13 | DISK_UUID = "64f281c4-5799-4608-88e2-cea581f515d8" |
14 | MOUNT_POINT = "/mnt/backup" |
15 | |
16 | |
17 | def sh(cmd): |
18 | print('$ ' + cmd) |
19 | os.system(cmd) |
20 | |
21 | def mount(): |
22 | sh("mkdir -p {}".format(MOUNT_POINT)) |
23 | sh("mount UUID='{}' {} -o compress-force=zlib,noatime".format(DISK_UUID, MOUNT_POINT)) |
24 | |
25 | def umount(): |
26 | sh("umount {}".format(MOUNT_POINT)) |
27 | |
28 | def get_current_backup_path(): |
29 | return os.path.join(MOUNT_POINT, 'current') |
30 | |
31 | def create_snapshot(): |
32 | snap = os.path.join(MOUNT_POINT, time.strftime("snapshot-%Y-%m-%d-%H-%M-%S")) |
33 | sh("btrfs subvolume snapshot -r {} {}".format(get_current_backup_path(), snap)) |
34 | sh("ls -la {}".format(MOUNT_POINT)) |
35 | |
36 | def get_include_exclude_list(): |
37 | l = "" |
38 | for directory in INCLUDE: |
39 | l += '--include="{}" '.format(directory) |
40 | l += '--include="{}/**" '.format(directory) |
41 | l += '--exclude="*"' |
42 | return l |
43 | |
44 | def rsync(): |
45 | inc = get_include_exclude_list() |
46 | dest = get_current_backup_path() |
47 | if not os.path.exists(dest): |
48 | sh('btrfs subvolume create {}'.format(dest)) |
49 | sh('rsync --info=progress2 --delete -a -m {} / {}'.format(inc, dest)) |
50 | |
51 | def check_root(): |
52 | if os.geteuid() != 0: |
53 | sh('sudo {}'.format(__file__)) |
54 | exit() |
55 | |
56 | def main(): |
57 | check_root() |
58 | mount() |
59 | rsync() |
60 | create_snapshot() |
61 | umount() |
62 | |
63 | if __name__ == '__main__': |
64 | main() |
So sieht das dann aus:
1 | $ ls -la /mnt/backup |
2 | insgesamt 20 |
3 | drwxr-xr-x 1 root root 350 Mär 28 20:25 . |
4 | drwxr-xr-x 15 root root 4096 Mär 3 16:16 .. |
5 | drwxr-xr-x 1 root root 28 Mär 25 18:10 current |
6 | drwxr-xr-x 1 root root 28 Dez 16 17:05 snapshot-2018-01-22-23-20-55 |
7 | drwxr-xr-x 1 root root 28 Jan 22 23:34 snapshot-2018-01-23-00-30-36 |
8 | drwxr-xr-x 1 root root 28 Feb 23 17:52 snapshot-2018-03-11-18-35-29 |
9 | drwxr-xr-x 1 root root 28 Mär 15 17:29 snapshot-2018-03-24-18-18-29 |
10 | drwxr-xr-x 1 root root 28 Mär 15 17:29 snapshot-2018-03-24-18-26-07 |
11 | drwxr-xr-x 1 root root 28 Mär 25 18:10 snapshot-2018-03-28-20-25-04 |
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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) ;-)
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. ;)
Beitrag #5369538 wurde vom Autor gelöscht.
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
cron und '%': The entire command portion of the line, up to a newline or % character..
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:
1 | 0 2 * * * rsync -a --delete /media/pi/HD1/Verzeichnis/ /media/pi/HD2/Verzeichnis/ && touch /media/pi/HD2/Verzeichnis/letzte_Sicherung_am_$(date -I) |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.