Brauche einfache Bash hilfe (Datum automatisiert)?
Hallo Leute, ich habe gerade ein Blackout... Ich möchte eine Datei täglich kopieren mit crontab. Bis hier hin bekomme ich es selbst noch hin z.B.:
18 * * * sudo cd /home/user11/datei.sh /var/backup/datei.sh
Nun wird jeden Tag um 18Uhr die Datei kopiert aber leider auch überschrieben. Ich möchte gern, das automatisch ein Datum an die Datei geschrieben wird. z.b. datei-20170623 für das Backup von heute
Außerdem möchte ich dann auch automatisch vom heutigen Datum z.B. 7 Tage abziehen um den Befehl:
18 * * * sudo rm /var/backup/datei-20170616.sh
Ich hoffe ihr könnt mir sagen wie ich das umsetzen kann. Ich stehe gerade etwas auf dem Schlauch.
Danke und Gruß
5 Antworten
Hallo
Ich möchte gern, das automatisch ein Datum an die Datei geschrieben wird. z.b. datei-20170623 für das Backup von heute
So zum Beispiel könnte das Script aussehen:
#/bin/bash
# backup_a_file.sh
FILENAME="$(date +%A_%d.%m.%Y_%H:%M:%S)"
cp /home/user11/datei.sh /var/backup/datei$FILENAME.sh
if [ $(ls -1|wc -l) -gt "6" ];
then
rm -f $(ls -1t|head -n2|tail -n1)
fi
exit 0
"Der Cronjob sähe dann so aus:
18 * * * /pfad/wo/es/liegt/backup_a_file.sh
Linuxhase
Danke ich habe es jedoch schon so hier gelöst:
rm ./Backup/datei.sh.*.`date +%u`
cp ./datei.sh ./Backup/datei.sh.`date +%Y%m%d.%u`
ich hätte zwar zumindest um den löschbefehl ein "if" setzen können um die ersten 7 Tage die Fehlermeldung nicht zu haben aber für meine zwecke reichte das :)
Danke und Gruß
Ich wüde ein kleines Script machen, das wird sonst etwas unübersichtlich in der crontab.
Zum Kopieren mit dem Datum im Dateinamen (Datumsformat anpassbar, siehe "man date"):
#!/bin/bash
DATE=`date +%Y-%m-%d`
cp datei1.sh datei-$DATE.sh
Zum Entfernen von allem was älter als eine bestimmte Zeit ist:
find ./verzeichnis -mmin +10080 -exec rm {} \;
Entfernt beispielsweise alles im Verzeichnis was älter als 7 Tage ist (Achtung, gefährlich). Ginge natürlich auch mit obigem Script, einfach umgekehrt.
Die beiden Befehle kannst du in ein script packen.
Ich würde den find-Befehl noch etwas mehr spezifizieren (genauer Pfad, type, iname) damit nichts hart schief gehen kann.
Achtung!!! den Befehl habe ich nicht getestet
find /DEINPFAD/ -type f -iname "datei*.sh" -mtime -7 -print0 | xargs -0 -I {} rm {}
Wieso verwendest du nicht einfach -delete Option von find?
Kannst statt -print0 | xargs -0 -I {} rm {} auch einfach -delete angeben.
Also:
find /DEINPFAD/ -type f -iname "datei*.sh" -mtime -7 -delete
sollte doch genau das machen, was du geschrieben hast.
Ganz einfach, weil du mit xargs die Aufgaben parallelisieren kannst wenn du lustig bist, das gibt gut speed bei vielen Dateien und wenn man sich entschließt die Dateien nicht zu löschen sondern nur zu archivieren/moven musst du nur den rm befehl mit dem tar oder mv-Befehl austauschen. Also es ist meiner meinung nach flexibler
Flexibilitäts-Argument lass ich zählen.
Dass exec aber schneller ist, bezweifele ich. Ohne es getestet zu haben, aber laut manual ist -delete am schnellsten:
https://www.gnu.org/software/findutils/manual/html\_node/find\_html/Deleting-Files.html
The most efficient and secure method of solving this problem is to use
the ‘-delete’ action:
find /var/tmp/stuff -mtime +90 -delete
This alternative is more efficient than any of the ‘-exec’ or
‘-execdir’ actions, since it entirely avoids the overhead of
forking a new process and usingexecto run/bin/rm. It
is also normally more efficient thanxargsfor the same
reason. The file deletion is performed from the directory containing
the entry to be deleted, so the ‘-delete’ action has the same
security advantages as the ‘-execdir’ action has.
Hey danke das du flexibilität supportest ;)
Das exec-Argument von dir lass ich zählen aber wo bitteschön benutze ich exec???
Da habe ich mich halt verschrieben.
Wenn du den Link mal anschaust - oder dir anschaust, was ich daraus zitiert habe - steht da, dass -delete normalerweise schneller ist als exec UND print + xargs.
Ich habe es direkt über die Wochentage mit "date %u" realisiert. das war weniger schreibarbeit und es kann nicht sein, dass mal was ausversehen gelöscht wird.
Danke Gruß
kernash hat deine Frage ja schon sehr gut beantwortet.
Unabhängig davon:
sudo in einem crontab ist aber nicht die beste Lösung. Führe doch einfach crontab -e als root aus - dann läuft dein Skript komplett als root und du brauchst kein sudo.
Man führt normalerweise keine kritischen Befehle als root aus sondern man führt den Befehl als der User aus, dem die Dateien die gelöscht werden sollen, gehören. Dann fällt auch das sudo weg :)
man führt den Befehl als der User aus, dem die Dateien die gelöscht werden sollen, gehören.
Das ist nicht ganz richtig.
Zum Löschen ist es bekanntlich völlig irrelevant, wem die Dateien gehören. Löschen kannst du nur, wenn du Schreibrechte (und x) auf dem Verzeichnis besitzt, in dem die Datei liegt.
Hast du diese nicht, kannst du die Datei nicht löschen - ja, auch wenn du der Besitzer der Datei bist.
Und wer ist denn default der Besitzer von "/var/backup"?
Yep: root
Von daher kann man es sicherlich auch anders machen, wenn man es anders will. Aber ich sehe kein Problem, die Skripte als root auszuführen.
"Das ist nicht ganz richtig"
Natürlich ist das richtig. Solange du Besitzer bist
"Löschen kannst du nur, wenn du Schreibrechte (und x) auf dem Verzeichnis besitzt"
Mach doch mal aus Spass den Gegentest als normaler User:
touch test.log && chmod 000 test.log
rm -rf test.log
Und wenn du schon mit "default" kommst. Defaultmässig hat der User der die Datei anlegt die nötigen Berechtingunge seine Files zu löschen.
Man könnte meinen, das Unix-Rechtesystem wäre total easy. Vor allem verglichen, was Windows so hat.
Umso erstaunlicher, dass das trotzdem viele nicht wirklich verstanden haben.
touch test.log && chmod 000 test.log
rm -rf test.log
Ist mir bewusst, dass das geht. Das liegt aber nicht daran, dass du Besitzer der Datei bist - denn wenn du eine Datei löscht, sidn die Rechte der Datei irrelevant (mal abgesehen von vielleicht "die Datei ist schreibgeschützt"-Abfragen, wenn man das -f nicht verwendet).
Wie bereits gesagt: Es kommt einzig und allein auf die Rechte des Verzeichnisses an.
Mach mal den Test:
Wie du siehst, kann es durchaus vorkommen, dass du eine Datei nicht löschen kannst, obwohl du diese besitzt. Es kann auch sein, dass du eine Datei löschen kannst, die root besitzt und auf die du keine Rechte hast.
Auf die Verzeichnisrechte kommt es beim Löschen an.
Wieder etwas dazugelernt ;).
Und wenn du schon mit "default" kommst. Defaultmässig hat der User der die Datei anlegt die nötigen Berechtingunge seine Files zu löschen.
Jaaaa....
Die Voraussetzungen um Dateien anzulegen sind eben die gleichen wie um sie zu löschen. In beiden Fällen eben Schreib und x-Rechte.
Das heißt, kannst du eine Datei in einem Ordner erstellen, kannst du in diesem Ordner auch Dateien löschen.
Ist Zuckersüss das du so auf deine Verzeichnisrechte-Predigt bestehst obwohl keiner was dagegen gesagt hat und ich bin mir sicher er ist nicht auf den Kopf gefallen und weiß was er wo wie löschen darf sonst hätte er auch nach der Berechtigung gefragt. Also lass mal die Klugsheißeritis weg und mach es für den Jungen hier nicht komplexer als es eigentlich ist dann ist dir auch ein imaginärer Lolli sicher.
- Er hat die Dateien angelegt also hat er auch die Rechte da drauf! Sonst hätte er sie auch nicht anlegen können.
- Als Root "rm" in einem cronjob ausführen ist schlechte Schule! Das sagt dir jeder Pro = Ein Anfänger mit rm Erfahrung
- Sein vorhaben sollte in ein Skript ausgelagert werden. Ist sauberer, flexibler und modularer
- Wenn er nach Performance strebt dann sollte er sich xargs anstelle von exec und -delete ansehen
- Der cronjob sollte nur das machen für was es auch anfangs gedacht wurde: "Etwas stupide zu einer bestimmten Zeit ausführen und keine Programmierlogiken
- Fertig!
Hast du diese nicht, kannst du die Datei nicht löschen - ja, auch wenn du der Besitzer der Datei bist.
darauf sind schon Viele reingefallen!
Wenn du der Besitzer bist, kannst du jederzeit die Rechte so setzen, wie du sie brauchst. Linux umgeht das ( weil es der Owner ohnehin machen kann) und löscht die Datei, auch wenn write gemäß Zugriffsrechte nicht zulässig ist.
(write bedeutet verändern und da ist Löschen eingeschlossen)
@guenterhalt
Jetzt darfst du mal raten, wieso ein Verzeichnis Schreib-Rechte haben kann.
Würde mich wirklich mal interessieren, was ihr alle denkt, dass die bewirken.
Tipp: Write bei einem Verzeichnis bedeutet: Fähigkeit Dateien anlegen oder löschen.
Wenn du Owner einer Datei bist, kannst du den Dateiinhalt komplett löschen. Das die Datei aber ganz gelöscht ist, musst du das im Verzeichnis reinschreiben. Und dafür brauchst du Schreibrechte für das Verzeichnis.
Ich kann sogar eine Datei mit 0 Berechtigungen und ohne Owern zu sein löschen, wenn ich Schreibrechte im Verzeichnis habe.
Auch für dich - wenn du mir nicht glaubst - der Beweis zum selbst ausführen:
Um eines mal klarzustellen: Ich rede gerade mit dir und nicht mit dem Fragesteller.
Ich habe einzig und allein geschrieben, dass es doch besser ist Sachen direkt mit root auszuführen als mit dem sudo-Hack. Einziger Inhalt meiner Antwort. Wirst du mir doch zustimmen, oder?
Du hast darauf einen Kommentar geschrieben, der gezeigt hat, dass du das Unix-Rechtesystem nicht beherrscht.
Ich habe dies richtig gestellt und dir erklärt, wie es tatsächlich mit Unix-Rechtesystem aussieht.
Wenn du noch weitere Tipps für Takiry hast, kannst du die gerne schreiben. Dann aber wohl in einer eigenen Antwort - und nicht in einem Kommentar unter meiner Antwort.
Aber:
Root besser als sudo
Berechtigung zum Löschen ist einzig und allein durch Verzeichnis-Berechtigung bestimmt
Die 2 Sachen jetzt klar? Dann wären wir ja fertig.
@Tuxgamer2 da habe ich deinen Beitrag wohl nicht richtig gelesen.
Mein Kommentar mit "hereingefallen" bezog sich nur auf die Rechte der zu löschenden Datei.
Was das Schreiben im betreffenden Directory betrifft, dann sind deine Bemerkungen durchaus richtig.
Wenn
ein "nicht-owner" eine Datei löschen kann, dann erfolgt das in der
Regel über die Gruppen-Schreibrechte. Wer das großzügig zulässt kann
schon Pech haben.
Würde mich wirklich mal interessieren, was ihr alle denkt, dass die bewirken.
Was denkst du, was ein Rentner, der mal Linux-Systemadministrator war, so denkt?
@guenterhalt
Wenn
ein "nicht-owner" eine Datei löschen kann, dann erfolgt das in der
Regel über die Gruppen-Schreibrechte.
Wieso?
Kann doch genauso gut über Owner-Schreibrechte des Ordners gehen. Und ob ich Owner der Datei bin, ist beim Löschen sowieso egal.
Ohje da habe ich ja wieder was angerichtet...
Also sudo wird in meinem fall wirklich nicht benötigt. Das ist grundsätzlich richtig. Warum das noch da oben steht hatte ich oben gerade schon geschrieben. Ich habe es auf einem halb fertigen Script kopiert indiesem Script hatte ich sudo gebraucht da es von einem kleinen nutzer ausgeführt wurde zu testzwecken.
Also es war nur ein kleiner fehler von mir. Bitte nciht desswegen streiten. Ich denke wann wo wer welche Dateien löschen darf ist jedem klar. bei einigen Daten ist nun mal root der einzige der es darf darum wird sudo gebraucht. in meinem fall später wird dies nicht der fall sein aber das geht jetzt zu weit in die materie was ich vor haben...
Gruß und Danke
Wir streiten uns doch gar nicht ;) Du weißt doch wie das bei den Jungs ist. Immer weiß einer etwas besser als der andere und keiner hat den mum nachgeben. Hauptsache deine Frage wurde beantwortet
1. cron läuft als Superuser-Job, somit läuft so ein Job bereits mit root-Rechten, sudo ist dort völlig sinnlos.
2. cd ist "nur" ein in (hier der bash ) der Shell eingebauter Befehl.
sudo cd <anderes Verzeichnis> wird mit einer Fehlermeldung enden, da sudo ein Binary erwartet.
Möglicherweise ist cd auch nur ein Schreibfehler und sollte cp heißen(?).
3. auch wenn Linux Datei-Namen-Erweiterungen nicht benötigt, mit .sh werden zur Wiedererkennung Shell-Scrip-Dateien gekennzeichnet. Warum nennst du das Backup auch so?
4. das Datum im Dateinamen unterzubringen ist relativ einfach. Siehe die Man-Page von date.
Beispiel:
cp <meine-Datei> <Pfad>/<meine-Datei>.`date +%d%m%Y`
5. Zum Löschen alter Backup-Dateien würde ich einfach in das Datum der Erstellung den Wochentag aufnehmen
cp <meine-Datei> <Pfad>/<meine-Datei>.`date +%d%m%Y.%u`Vor dem Anlegen des neuen Backup kann dann das 7 Tage alte mit
rm <Pfad>/<meine-Datei>.*.`date %u` gelöscht werden.
1. ja da hast du recht. das hier war nur für die frage zusammenkopiert da ich bereits mal ein script angefangen hatte und da hatte ich root gebraucht... ach egal du hast da recht in dem vall wird sudfo nicht gebraucht. War ein Fehler bei der frage auf dem System ist es bei mir richtig.
2. Ja soory auch nur ein schreibfehler. Wäre ja quatsch das Verzeichnis beim kopieren zu wechseln :D
3. ich habe mir das so angewohnt dass ich beim backup alle andungen usw behalte. Es sollen nicht nur .sh datein kopiert werden sondern auch viele andere formate. darum lass ich immer die andung dran. warum ich das oben mal vor und mal nach dem datum schreibe weiß nur der liebe gott xD
4. Danke perfekt
5. das mit %u ist natürlich eine geniale idee... Das erspart viel hin und her gerechne. Danke dafür. Daran habe ich nie gedacht.
Zusammenfassend muss ich sagen das du meine frage sehr genau gelesen hast und jede menge fehler bei mir entdeckt hast. Tja war ich vorhin doch zu schnell beim Fragen. Danke für die ausführliche antwort
Das Datum von vor einer Woche wäre dann: