rm /*

[Spacepilot]

Hallo erstmal an Alle!

Oh man, ich hab grade aus Versehen als SU

Code: Alles auswählen

rm /* 

eingegeben. (Wollte eigentlich nur unterhalb des aktuellen Verzeichnisses alle Verz. löschen)
Der Befehl hatte aber gewisse Nebenwirkungen...
Gibt es Möglichkeiten die Wirkung des Befehls aufzuheben?

Welche Möglichkeiten gibt es, ein konfiguriertes System mit allen installierten Packages
zu sichern und schnell wieder herstellen zu können? (außer die Festplatte zu spiegeln bzw. ein komplettes Image zu erstellen)
Wo kann ich das gut nachlesen?

Danke im Voraus

[Fjunchclick]

Hallo, das hier sollte dir weiterhelfen:
http://wiki.ubuntuusers.de/Datensicherung

[wanne]

Wow was so ein fehlender Punkt verändern kann...

[trompetenkaefer]

Sollten wichtige Dokumente, Musikdateien etc. fehlen würde ich mal photorec drüberlaufen lassen... Ein Bekannter hatte Gestern das selbe Problem, mit photorec konnten wir die gelöschten MP3s schließlich wiederherstellen.

[Meillo]

Du hast hoffentlich sofort das Stromkabel gezogen. Dann die Platte clonen und nur auf der Kopie arbeiten. Das jedenfalls solltest du tun wenn du wichtige Daten drauf hast .... aber obwohl, wenn es wichtige Daten sind, dann hast du ja sicher Backups.

[uname]

Schau auch hier: http://de.wikipedia.org/wiki/IT-Forensik

Der Grund ist zwar ein anderer, das Vorgehen ist jedoch ähnlich.

[michaels]

Bin ich gerade blind, oder dürfte eigentlich nicht viel passiert sein? Verzeichnisse wurden doch gar nicht angefasst (da kein -r)...also sind "nur" die Links auf initrd.img und vmlinuz gelöscht, oder irre ich mich da gerade!?

[Danielx]

Wenn wichtige Daten gelöscht wurden:
Sofort ausschalten, Image erstellen (z.B. mit dd) und nur auf diesem arbeiten.
Falls EXT3 verwendet wird, mit extundelete die Daten wieder herstellen.

Bin ich gerade blind, oder dürfte eigentlich nicht viel passiert sein?

Ja.

Gruß,
Daniel

[manes]

Bin ich gerade blind, oder dürfte eigentlich nicht viel passiert sein?

Ja.

oder-frage, danielx!
kann hier mal wer eine umfrage einrichten und wir stimmen ab, was passiert sein kann!
manes

[hkalegre]

Probiers in der Virtualbox aus:

1) Snapshot
2) rm /*
3) Links sind weg, sonst nichts

[Danielx]

oder-frage, danielx!

Das Komma hat mich irritiert.
Meine Antwort bezog sich auf den zweiten Teil des Satzes.

Gruß,
Daniel

[Spacepilot]

Danke für die Antworten!

"nur" die Links auf initrd.img und vmlinuz gelöscht

3) Links sind weg, sonst nichts

echt?
Wie hätte man die wieder setzen können?
Ich konnte irgendwie keinen Terminal mehr öffnen. (war vielleicht der nächste Fehler den Aktuellen zu schließen.)
Über X wurden zwar noch die Verzeichnisse aber keine Inhalte mehr angezeigt.
Bin mir nicht mehr sicher ob der Rechner sich noch herunterfahren ließ.
Auf jeden Fall ließ sich das OS danach nicht mehr starten.


Angenommen man hat ein Image von sda1 (wo sich / befindet). Und das OS ist unbrauchbar geworden.

Kann man nun, ohne Neuinstallation, mit einer live-cd o.ä. einfach das image wieder zurück kopieren. Um wieder zu einem funktionierenden System zu gelangen?

spricht was dagegen rsync ein gepacktes Ziel vorzusetzen?
z.B. ein Image auf einem Speicherstick?

[suno]

Kann man nun, ohne Neuinstallation, mit einer live-cd o.ä. einfach das image wieder zurück kopieren. Um wieder zu einem funktionierenden System zu gelangen?

boote von einer live-cd, stelle die ~5 links wieder her (manuell mit ln-s als root) und alles ist ok.
Hier wie es aussehen sollte

Code: Alles auswählen

sa@wks:~$ type la; la /
la is aliased to `ls -la'
total 125
drwxr-xr-x  23 root root  4096 Jun  1 21:06 .
drwxr-xr-x  23 root root  4096 Jun  1 21:06 ..
drwxr-xr-x   2 root root  4096 Jun  1 21:26 bin
drwxr-xr-x   4 root root  1024 Jun  5 17:09 boot
lrwxrwxrwx   1 root root    11 Jun  1 09:43 cdrom -> media/cdrom
drwxr-xr-x  19 root root  3480 Jun  2 12:50 dev
drwxr-xr-x 196 root root 12288 Jun  6 11:27 etc
drwxr-xr-x   3 root root  4096 Jun  1 10:29 home
lrwxrwxrwx   1 root root    30 Jun  1 12:01 initrd.img -> boot/initrd.img-2.6.32-5-amd64
lrwxrwxrwx   1 root root    30 Jun  1 10:01 initrd.img.old -> boot/initrd.img-2.6.32-3-amd64
drwxr-xr-x  14 root root 16384 Jun  6 00:09 lib
drwxr-xr-x   4 root root 12288 Jun  2 07:46 lib32
lrwxrwxrwx   1 root root     4 Jun  1 09:44 lib64 -> /lib
drwx------   2 root root 16384 Jun  1 09:43 lost+found
drwxr-xr-x  11 root root  4096 Jun  1 21:16 media
drwxr-xr-x   2 root root  4096 Apr 24  2009 mnt
drwxr-xr-x   3 root root  4096 Jun  1 21:06 mozilla
drwxr-xr-x   2 root root  4096 Jun  1 09:44 opt
dr-xr-xr-x 254 root root     0 Jun  2 12:49 proc
drwxr-xr-x  32 root root  4096 Jun  6 00:09 root
drwxr-xr-x   2 root root 12288 Jun  5 17:08 sbin
drwxr-xr-x   2 root root  4096 Feb 12  2009 selinux
drwxr-xr-x   4 root root  4096 Jun  1 21:27 srv
drwxr-xr-x  13 root root     0 Jun  2 12:49 sys
drwxrwxrwt  23 root root  4096 Jun  6 13:10 tmp
drwxr-xr-x  12 root root  4096 Jun  1 23:10 usr
drwxr-xr-x  15 root root  4096 Jun  1 21:00 var
lrwxrwxrwx   1 root root    27 Jun  1 12:01 vmlinuz -> boot/vmlinuz-2.6.32-5-amd64
lrwxrwxrwx   1 root root    27 Jun  1 10:01 vmlinuz.old -> boot/vmlinuz-2.6.32-3-amd64
sa@wks:~$ 

[suno]

Du hast hoffentlich sofort das Stromkabel gezogen.

das hilft z.b. bei xfs und btrfs & Co genau gar nichts weil die commands in einen oplog geschrieben werden und sobald die Maschine wieder strom hat diese exekutiert wird. Kabel ziehen ist wie verhueten mit der zieh-frueh-genug-raus methode ... quatsch.

[Meillo]

Du hast hoffentlich sofort das Stromkabel gezogen.

das hilft z.b. bei xfs und btrfs & Co genau gar nichts weil die commands in einen oplog geschrieben werden und sobald die Maschine wieder strom hat diese exekutiert wird.

Ich kenne die Internals dieser Dateisysteme nicht. Falls diese irgendwelche Hardwarefeatures verwenden, dann kannst du recht haben.

Falls ich die Platte aber (mit einem anderen System) direkt vom Device kopiere ohne das Filesystem zu mounten, dann sollte im Filesystem nichts geändert werden.

Kabel ziehen ist wie verhueten mit der zieh-frueh-genug-raus methode ... quatsch.

Damit hat es mal gar nichts zu tun.

[suno]

Ich kenne die Internals dieser Dateisysteme nicht. Falls diese irgendwelche Hardwarefeatures verwenden, dann kannst du recht haben.

Nein, der oplog ist teil der metadaten, "wohnt" also direkt im filesystem. Ein kausaler Zusammenhang existiert nicht.

[Meillo]

Ich kenne die Internals dieser Dateisysteme nicht. Falls diese irgendwelche Hardwarefeatures verwenden, dann kannst du recht haben.

Nein, der oplog ist teil der metadaten, "wohnt" also direkt im filesystem.

Was hast du dann gegen das Steckerziehen? Insbesondere da das vielmehr gegen das Überschreiben von kürzlich freigegebenen Blocks durch irgendwelche Schreibzugriffe des Betriebssystems in Hintergrund hilft und somit nichts mit oplogs zu tun hat.

Wenn man versehentlich Dateien gelöscht (= Blocks als unbenutzt markiert) hat und diese Daten wiederherstellen will, dann ist es sinnvoll jeden weiteren Schreibzugriff auf das Dateisystem zu verhindern. Am besten geht das durch das schnellstmögliche Anhalten des Systems (= Strom weg).

Wenn man dan die Platte in ein anderes System einbaut ohne zu mounten (!), dann kann man das Festplattendevice durchsuchen und Daten rekonstruieren. Je weniger der als unbenützt markierten Blöcke neu beschrieben wurden, desto mehr alte Daten kann man noch rausholen.

Liege ich falsch?

[gms]

Du hast hoffentlich sofort das Stromkabel gezogen.

das hilft z.b. bei xfs und btrfs & Co genau gar nichts weil die commands in einen oplog geschrieben werden und sobald die Maschine wieder strom hat diese exekutiert wird. Kabel ziehen ist wie verhueten mit der zieh-frueh-genug-raus methode ... quatsch.

auch bei XFS werden die Blöcke der gelöschten Dateien nicht sofort überschrieben:
http://xfs.org/index.php/XFS_FAQ#Q:_Doe ... ability.3F

manche Journaling-Filesystems erlauben auch ein Löschen des Journals, bzw ext3 kann auch als ext2 gemountet werden

Gruß
gms

[suno]

Was hast du dann gegen das Steckerziehen? Insbesondere da das vielmehr gegen das Überschreiben von kürzlich freigegebenen Blocks durch irgendwelche Schreibzugriffe des Betriebssystems in Hintergrund hilft und somit nichts mit oplogs zu tun hat.

Es ist halt aber so das der fsync intervall beim oplog im vergleich zu dem der Nutzdaten sehr gering ist (ein Vergleich mit dem write-ahead log bei PostgresSQL ist da passend). Stecker ziehen, naja, kann man machen, ob es was hilft ist die andere Frage. Wenn er einen RAID Kontroller mit write-trough Faehigkeit und BBU hat, was dann?
Wir kommen vom Thema ab, es geht ja hier gluecklichweise nur um sechs sym links.

[Danielx]

3) Links sind weg, sonst nichts

echt?

Ja, wenn es "rm /*" war.

Ich konnte irgendwie keinen Terminal mehr öffnen. (war vielleicht der nächste Fehler den Aktuellen zu schließen.)

Bist du dir sicher, dass es wirklich "rm /*" war und nicht z.B. "rm -r /*"?
Denn mit "rm /*" lässt sich das nicht erklären.

Wer ausprobieren möchte, was rm löschen würde, der kann den Schalter "-i" verwenden.
Für "rm /*" wäre das dann z.B. folgender Befehl, aber bitte immer mit "n" antworten, sonst wird wirklich gelöscht:

Code: Alles auswählen

rm -i /*

Bei mir sieht das dann so aus:

rm: Entfernen von „/bin“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/boot“ nicht möglich: Ist ein Verzeichnis
rm: symbolische Verknüpfung „/cdrom“ entfernen? n
rm: Entfernen von „/dev“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/etc“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/home“ nicht möglich: Ist ein Verzeichnis
rm: symbolische Verknüpfung „/initrd.img“ entfernen? n
rm: symbolische Verknüpfung „/initrd.img.old“ entfernen? n
rm: Entfernen von „/lib“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/lost+found“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/media“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/mnt“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/opt“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/proc“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/root“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/sbin“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/selinux“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/srv“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/sys“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/tmp“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/usr“ nicht möglich: Ist ein Verzeichnis
rm: Entfernen von „/var“ nicht möglich: Ist ein Verzeichnis
rm: symbolische Verknüpfung „/vmlinuz“ entfernen? n
rm: symbolische Verknüpfung „/vmlinuz.old“ entfernen? n

Es würden also nur die von mir hervorgehobenen Links gelöscht.

Gruß,
Daniel

[wanne]

rm: symbolische Verknüpfung „/initrd.img“ entfernen? n
rm: symbolische Verknüpfung „/vmlinuz“ entfernen? n

Ich nehme an das reicht um das System vollständig lahm zu legen.

boote von einer live-cd, stelle die ~5 links wieder her (manuell mit ln-s als root) und alles ist ok.

Das müsste stimmen.

[kolja]

Ich nehme an das reicht um das System vollständig lahm zu legen.

Nö, das stört frühestens beim nächsten Booten. Und je nach Bootloader (lilo!) nicht mal dann.

[Spacepilot]

Bist du dir sicher, dass es wirklich "rm /*" war und nicht z.B. "rm -r /*"?
Denn mit "rm /*" lässt sich das nicht erklären.

Ja, ganz sicher.
Außer den von dir schon aufgeführten
wurden noch die Links auf lib32 und lib64 entfernt.

Hab das System mittlerweile neu aufgesetzt.

Danke + Gruß

[Danielx]

Außer den von dir schon aufgeführten
wurden noch die Links auf lib32 und lib64 entfernt.

Achso, also war das ein AMD64-Debian.

Gruß,
Daniel

[Spacepilot]

...genau, 64bit.

THX!