wired2051
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
Ich hoffe, ich bin hier richtig. Auf meinem NAS (Synology DS209) läuft ein Backup (TimeBackup), dass im Ergebnis einen Verzeichnisbaum ähnlich von rsnapshot anlegt (also mit Hardlinks). Nun will ich eine besonders grosse Datei in allen Sicherungen löschen. Ich habe mich via telnet als root auf dem NAS eingeloggt und finde mit DS209> cd /volume2/Time\ Backup/TimeBackup/
DS209> pwd
/volume2/Time Backup/TimeBackup
DS209> find -mindepth 7 -maxdepth 7 -depth -type f -name "*NAMENSTEIL*"
auch die gesuchten Files, doch wie geht es weiter? Lösche ich mit -delete oder besser mit -exec rm -rf {} \;? Gerade bei letzterer Variante bin ich mir mit der Syntax nicht sicher. 😳 Oder ist es trotz der Hardlinks ungefährlich, alle Dateien einzeln manuell (mit einem Dateimanager) zu löschen? Ich bin mir trotz Wikipedia-Lektüre nicht sicher, ob ich das mit den Hardlinks richtig verstanden habe. 😳 Moderiert von rklm: Angabe der Distribution entfernt und Titel angepasst
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Wenn du dir wirklich sicher bist, daß die gefundenen Sachen (die du dir bereits hast anzeigen lassen) gelöscht werden sollen, dann kannst du als /letzten/ Parameter -delete anhängen. Bei rm statt -rf lieber -i dann wirst du nochmals gefragt. find #irgendwas# -type f -exec rm -i {} + Oder erstmal in ein anderes Verzeichnis verschieben/umbenennen zum manuellen Sichten und Löschen. Je nach Backupkonzept gibts das auch gar nicht, daß man einzelne Dateien löscht oder das Backup sonstwie modifiziert. (Einmal angelegtes Backup ist und bleibt read-only um Verfälschungen weitgehend auszuschließen).
|
egi@lubuntu
Anmeldungsdatum: 25. November 2015
Beiträge: 71
|
rm -rf löscht rekursiv Verzeichnisse und Ihren Inhalt. D.h. der Befehl löscht u.U. mehr als was find angezeigt hat. Du schränkst ja find auf die 7. Ebene ein, gehst dann aber mit dem Parameter -r "in die Tiefe". Also lieber mit -delete löschen. Gruß
egi
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
Einfachstes Vorgehen: Du identifizierst eine Kopie dieser Datei. Dann: | find /wo/auch/immer -samefile /die/eine/Kopie -print -delete
|
Der "-print" ist nur dazu da, dass Du siehst, wo sie überall liegt. Zum Testen erst mal den "-delete" weglassen! frostschutz schrieb:
Je nach Backupkonzept gibts das auch gar nicht, daß man einzelne Dateien löscht oder das Backup sonstwie modifiziert. (Einmal angelegtes Backup ist und bleibt read-only um Verfälschungen weitgehend auszuschließen).
Da stimme ich zu. Wenn man eine Datei einfach so löscht, wird ggf. das gesamte Backup unbrauchbar. Ggf. ist es erfolgversprechender, die Datei auf Länge 0 zu kürzen. Das muss man dann auch nur einmal machen:
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
Vielen Dank für die Hilfe. Und ich habe auch verstanden warum besser -delete. 👍 Verschieben wäre natürlich sicherer aber lauter Dateien gleichen Namens können ja nicht in einem Verzeichnis abgelegt werden. Ich könnte find eine Datei mit Pfad und Namen erstellen lassen... Aber ich glaube, dass ist mir zu aufwendig. Wenn ich mir erst alle Dateien von find anzeigen lasse und dann -delete ranhänge, bin ich doch auch auf der sicheren Seite. Inwiefern ist denn die Reihenfolge der Parameter bei find wichtig? Das höre ich zum ersten mal. 😳 frostschutz schrieb: Je nach Backupkonzept gibts das auch gar nicht, daß man einzelne Dateien löscht oder das Backup sonstwie modifiziert. (Einmal angelegtes Backup ist und bleibt read-only um Verfälschungen weitgehend auszuschließen).
Also ich nehme ja an, das läuft mit/wie rsnapshot und da konnte ich auch immer einzelne Dateien manipulieren (wegen Hardlinks wird Speicherplatz erst frei, wenn letzte Datei gelöscht). Die fragliche Datei hat, wie offenbar alle Dateien im Backup die Rechte -rwx-––- 16 root root. Das spräche ja für ein von root modifizierbares Konzept, oder? Im Synology-Forum riet man mir die Dateien manuell zu löschen, imho spricht auch dass für ein modifizierbares Backupkonzept. (Aber ich will ja mehr über die Anwendung der Konsole lernen. 😉) Edit: rklm schrieb: | find /wo/auch/immer -samefile /die/eine/Kopie -print -delete
|
Wieder was gelernt. Danke. 👍 Und /die/eine/Kopie braucht den Absoluten Pfad auch wenn dieser innerhalb /wo/auch/immer liegt? OK, ist vermutlich sicherer. rklm schrieb: Ggf. ist es erfolgversprechender, die Datei auf Länge 0 zu kürzen. Das muss man dann auch nur einmal machen:
Interessant. Also statt finde nur echo -n >|/PFAD/DATEINAME. Aber wenn im Backup unterschiedliche Datei mit gleichem Namen liegen (sie wurden verändert und nehmen deshalb zu viel Platz weg) muss man das doch für jede Version machen? Da käme dann wieder find ins Spiel. find -mindepth 7 -maxdepth 7 -depth -type f -name "*NAMENSTEIL*" -exec echo -n >|DATEINAME {} \; Richtig?
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
wired2051 schrieb:
rklm schrieb: | find /wo/auch/immer -samefile /die/eine/Kopie -print -delete
|
Wieder was gelernt. Danke. 👍 Und /die/eine/Kopie braucht den Absoluten Pfad auch wenn dieser innerhalb /wo/auch/immer liegt? OK, ist vermutlich sicherer.
Nein, braucht sie nicht, denn find muss das ja nur einmal auswerten.
rklm schrieb: Ggf. ist es erfolgversprechender, die Datei auf Länge 0 zu kürzen. Das muss man dann auch nur einmal machen:
Interessant. Also statt finde nur echo -n >|/PFAD/DATEINAME. Aber wenn im Backup unterschiedliche Datei mit gleichem Namen liegen (sie wurden verändert und nehmen deshalb zu viel Platz weg) muss man das doch für jede Version machen? Da käme dann wieder find ins Spiel.
Ich hatte Deinen Fall so verstanden, dass dieselbe große Datei per Hardlink in jedem Backup steckt. Wenn Du nur eine Datei mit einem speziellen Namen suchst, die aber in unterschiedlichen Ständen da ist, dann muss man es natürlich anders machen. Übrigens kannst Du auch -path verwenden, wenn Du z.B. weißt, dass die Datei immer an einer bestimmten Stelle im Verzeichnisbaum steht - das ist etwas selektiver als nur der Name: | find -path '*/foo/bar/name' ...
|
find -mindepth 7 -maxdepth 7 -depth -type f -name "*NAMENSTEIL*" -exec echo -n >|DATEINAME {} \; Richtig?
Nein, so geht das nicht, weil Du ja das Ziel der Umleitung erst durch den find ermitteln lassen musst. Du brauchst eher so etwas: | find -mindepth 7 -maxdepth 7 -depth -type f -name '*NAMENSTEIL*' -exec sh -c 'echo -n >|"$0"' {} \;
|
oder auch | find -mindepth 7 -maxdepth 7 -depth -type f -name '*NAMENSTEIL*' -exec sh -c 'for f; do echo -n >|"$f"; done' -- {} +
|
(weniger Prozesse)
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
Also, ich finde die Dateien jetzt mit folgenden Varianten auf dem NAS: | DS209> cd /volume2/Time\ Backup/TimeBackup/
DS209> pwd
/volume2/Time Backup/TimeBackup
DS209> find -mindepth 7 -maxdepth 7 -depth -type f -name "*NAMENSTEIL*"
DS209> find -mindepth 7 -maxdepth 7 -depth -type f -path "*PFAD/UNTER/AKTUELLEM/VERZEICHNIS/DATEINAME.*"
DS209> find -depth -type f -path "*PFAD/UNTER/AKTUELLEM/VERZEICHNIS/DATEINAME.*"
|
Das macht mich fast schon glücklich, wäre da nicht diese Neugier: Gefühlt dauern alle Suchen gleich lang, welche ist sinnvoller? frostschutz meinte, dass -delete als letzter Parameter angehangen werden sollte. Welche Rolle spielt die Reihenfolge bei den Parametern von find?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
wired2051 schrieb: frostschutz meinte, dass -delete als letzter Parameter angehangen werden sollte. Welche Rolle spielt die Reihenfolge bei den Parametern von find?
Jeder Parameter ist sozusagen ein Filter der einer nach dem anderen angewendet wird und die Auswahl einschränkt. Wenn du -delete nicht ans Ende setzt, greifen deine Einschränkungen und Kriterien nicht. Es wird dann einfach alles gelöscht. Das gilt auch für alle anderen Parameter, -exec gehört ja genauso ans Ende wenn man es nur für die gefundenen Dateien ausführen möchte, -print0 am Ende wenn nur die gefundenen Dateien nullterminiert ausgegeben werden sollen (für xargs -0, sort -z, ...)
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
So, habe jetzt mit find -depth -type f -path "*PFAD/UNTER/AKTUELLEM/VERZEICHNIS/DATEINAME.*" -delete gelöscht. Dabei gab es allerdings während des Such-/Löschvorgangs, anders als beim Suchvorgang ohne -delete keine Ausgabe der gefundenen Dateien. Wäre also nächstes mal -print richtig um die Ausgabe zu beklommen? | find -depth -type f -path "*PFAD/UNTER/AKTUELLEM/VERZEICHNIS/DATEINAME.*" -print -delete
|
Ausserdem will/muss ich noch mehrere Verzeichnisse im Backup löschen. Kann man das beschleunigen, in dem man mehrere Verzeichnisse gleichzeitig sucht und löscht? Der letzte Vorgang hat immerhin 8h gedauert...
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Ich fürchte, da geht nix mit "beschleunigen", denn im Prinzip ist find schon ± so schnell wie es das I/O der Platte zulässt ... Ich kenne Deine Platte ja nun nicht, aber meist ist das der Flaschenhals bei den modernen GB- Platten, dass da im Verhältnis zur Zugriffsgeschwindigkeit so irrsinnig viel Zeug drauf passt. Gut, 8 Stunden sind da schon sehr viel. War die Platte womöglich über USB 2 angeschlossen ? LG, track
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
track schrieb: Ich fürchte, da geht nix mit "beschleunigen", denn im Prinzip ist find schon ± so schnell wie es das I/O der Platte zulässt ... Ich kenne Deine Platte ja nun nicht, aber meist ist das der Flaschenhals bei den modernen GB- Platten, dass da im Verhältnis zur Zugriffsgeschwindigkeit so irrsinnig viel Zeug drauf passt. Gut, 8 Stunden sind da schon sehr viel. War die Platte womöglich über USB 2 angeschlossen ?
Es sind HDS722020ALA330 2TB 32MB 7200U/min. SATA von Hitachi. Ich dachte/denke aber, das liegt eher am NAS in dem sie verbaut sind, eine DS209 von Synology (Datasheet, PDF), CPU 1.2GHz und RAM 256MB. Angeschlossen mit 1 Gbit/s LAN. Also mehrere Verzeichnisse gleichzeitig suchen/löschen geht nicht? Aber die Anwendung von find mit -print -delete ist richtig?
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
wired2051 schrieb: ... liegt eher am NAS in dem sie verbaut sind, eine DS209 von Synology (Datasheet, PDF), CPU 1.2GHz und RAM 256MB. Angeschlossen mit 1 Gbit/s LAN.
Ja, die CPU des NAS ist wohl der Flaschenhals, würde ich sagen. Denn die muss ja letztlich die ganzen Dateisystem-Zugriffe handeln. Und dann sind es auch noch 2 Stück, wenn ich recht verstehe, was auch noch etwas Overhead hinzufügt ... Also mehrere Verzeichnisse gleichzeitig suchen/löschen geht nicht?
Geht, aber bringt nichts. - außer dass die arme CPU zusätzlich auch noch ständig swappen muss. 😉 Aber die Anwendung von find mit -print -delete ist richtig?
Denke ich, ja. Aber warum bist Du Dir da unsicher ? LG, track p.s.: ich bin jetzt erstmal unterwegs, heute Nacht gucke ich wieder.
|
Vain
Anmeldungsdatum: 12. April 2008
Beiträge: 2503
|
Vielleicht musst du mal den Kraft-Knopf drücken … scnr. Hast du das über’s Netzwerk gemountet? Hast du alternativ direkten SSH-/Telnet-Zugriff auf das Ding? Den Löschvorgang lokal ohne Overhead eines Netzwerkprotokolls zu starten (im Idealfall in screen), könnte nochmal eine Idee schneller sein. Erwähnt ist SSH zumindest im Datenblatt. (Eine ARM-CPU ist da übrigens drin, kein „normaler“ x86_64. Kann ich überhaupt nicht einschätzen, wie schnell das Ding sein könnte – Festplatten sind immerhin elend lahm im Vergleich zu so ’ner CPU, also könnte ich mir schon vorstellen, dass die CPU möglicherweise nicht der Flaschenhals ist. Kannst du htop oder sowas auf dem NAS starten und gucken, wie hoch die CPU-Last da wirklich ist, während du Verzeichnisbäume abläufst? Würde mich mal interessieren. Rein aus Neugier.)
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
Vain schrieb: Kannst du htop oder sowas auf dem NAS starten und gucken, wie hoch die CPU-Last da wirklich ist, während du Verzeichnisbäume abläufst? Würde mich mal interessieren. Rein aus Neugier.)
Kann ich gerne machen. Jetzt muss ich erst mal das mit dem Suchen/Löschen klären. Die zu finden Verzeichnisse sind nach diesem Muster gespeichert: /volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160916-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160927-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160927-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160924-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160924-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160923-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160923-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160922-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160922-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/ Ich gehe mit Konsole V 2.13.2 über Telnet (ohne ssh) auf das NAS. Ich würde jetzt folgende Suche starten: | DS209> cd /volume2/Time\ Backup/TimeBackup/DS209_001132064510/task_1/
DS209> find -depth -type d -path "/PC-TriOptimum/USER/Desktop/*SUCHSTRING/" -print -delete
|
Ist das korrekt? Ich bin unsicher, weil der SUCHSTRING mehrfach vorkommt und teilweise vorher noch Zeichen im Verzeichnisnamen sind.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
wired2051 schrieb:
Jetzt muss ich erst mal das mit dem Suchen/Löschen klären. Die zu finden Verzeichnisse sind nach diesem Muster gespeichert: /volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160916-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160927-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160927-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160924-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160924-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160923-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160923-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160922-1030/PC-TriOptimum/USER/Desktop/*SUCHSTRING/SUCHSTRING/
/volume2/Time Backup/TimeBackup/DS209_001132064510/task_1/20160922-1030/PC-TriOptimum/USER/Desktop/SUCHSTRING/
Was genau ist das "Muster"? Das sind ja offensichtlich nicht komplett originale Dateinamen. Und es ist mir nicht wirklich klar, was Dein Kriterium für die Löschung sein soll.
Ich gehe mit Konsole V 2.13.2 über Telnet (ohne ssh) auf das NAS. Ich würde jetzt folgende Suche starten: | DS209> cd /volume2/Time\ Backup/TimeBackup/DS209_001132064510/task_1/
DS209> find -depth -type d -path "/PC-TriOptimum/USER/Desktop/*SUCHSTRING/" -print -delete
|
Ist das korrekt?
Wie sollen wir das wissen? Du bist doch derjenige, der etwas löschen will. Und "SUCHSTRING" ist ja offensichtlich nicht das, wonach Du tatsächlich suchst.
Ich bin unsicher, weil der SUCHSTRING mehrfach vorkommt und teilweise vorher noch Zeichen im Verzeichnisnamen sind.
Dann führ es doch ohne -delete aus und schau, welche Ergebnisse Du bekommst. Klar ist auf jeden Fall, wenn Du nur nach Verzeichnissen suchst und mit -delete löscht, dass es dann nur für leere Verzeichnisse funktioniert. Wenn Du die samt Inhalt loswerden willst - was mir wahrscheinlich erscheint -, dann musst Du so etwas wie "-exec rm -rf {} +" für die gefundenen Verzeichnisse verwenden.
|