# Ripristino dopo un rm -r /etc

## kevinlux

Salve a tutti,

purtroppo per sbaglio dovevo cancellare una directory chiamata "etc" all'interno di una local directory della mia home,

pero' come il cretino ho scritto 

```
rm -r /etc 
```

 ma grazie a dio me ne sono accorto subito 

e dopo 1 secondo ho stoppato, tuttavia molti file sono stati cancellati,

al boot una serie d'errori di udev mi tappezzano lo schermo ma riesco a raggiungere la console

c'e' modo con un emerge qualcosa di sistemare il tutto? E si come?

Non vorrei partire daccapo con una nuova installazione!

Thx

----------

## Cazzantonio

niente che io sappia (a parte ricreare a mano tutti i files necessari)

la prossima volta ti consiglio di usare questi alias

```
alias rm='rm -i --preserve-root'

alias cp='cp -i'

alias mv='mv -i'

alias chgrp='chgrp --preserve-root'

alias chmod='chmod --preserve-root'

alias chown='chown --preserve-root'
```

in modo che ti venga chiesta quantomeno la conferma prima della tragedia

ovviamente conviene SEMPRE avere dei backup... fare un tar.gz di /etc costa poca fatica e rende molto... fare un tar.gz di tutto il sistema è solo poco più faticoso ma ESTREMAMENTE utile... 

P.S. uno che abbia un'istallazione "simile" alla tua potrebbe provare a passarti la sua etc e vedere che succede... tentare a questo punto non nuoce

----------

## cloc3

 *kevinlux wrote:*   

> 
> 
> Non vorrei partire daccapo con una nuova installazione!
> 
> 

 

prova:

```

emerge -eK world -pv

```

se hai conservato i binari, dovresti ottenere una reinstallazione rapida, compresa una /etc decente

(non esattamente uguale a quella rimossa).

per il file system ext3 esistono tool di recover.

cerca con google.

----------

## kevinlux

purtroppo ho una reiser e non conosco nessuno che abbia una installazione simile alla mia

tra l'altro ho compilato anche con i flag adatti al processore.

Va beh pazienza....mkreiserfs /dev/hda1 e perdo la nottata!

----------

## strites

mah al limite, se hai/ricrei il make.conf e qualche file necessario, con un 

```
emerge -e world
```

 dovresti risolvere pressappoco tutto... no?

----------

## X-Drum

 *strites wrote:*   

> mah al limite, se hai/ricrei il make.conf e qualche file necessario, con un 
> 
> ```
> emerge -e world
> ```
> ...

 

se riesce ad avviare emerge correttamente (non si registrano quindi disfunzioni)

un 

```
emerge -e world
```

 dovrebbe essere sufficiente

----------

## kevinlux

sono riuscito con un 

```
emerge -e world
```

 dopo aver sistemato pero' il make.conf e qualche altro file 

che aveva cancellato.

Grazie a tutti.

----------

## xdarma

 *Quote:*   

>  ... come un cretino ho scritto 
> 
> ```
> rm -r /etc 
> ```
> ...

 

Purtroppo ho combinato una caXXXata simile.

La /etc è completamente andata, l'ultimo stage4 è molto vecchio, ma almeno make.conf era stato salvato recentemente.

Prima di rigenerare tutto con una Knoppix ed "emerge -e world" e sovrascrivere definitivamente gli inode, volevo tentare di recuperare i file con debugfs (uso ext3) ma il comando lsdel non mi restituisce inode cancellati.

Anche su altre partizioni ext3, non toccate dalla disgrazia, debugfs -> lsdel non restituisce inode cancellati.

Ma ext3 è recuperabile o no?

La partizione con /etc veniva montata con il flag noatime e come feature avevo impostato solo "dir_index".

Può essere che impedisca il funzionamento di debugfs?

Se ext3 non ha l'undelete, tanto vale usare XFS o ReiserFS, tanto quello che c'è dentro lo perdi lo stesso...

----------

## .:chrome:.

l'"undelete" ufficialmente non esiste

----------

## xdarma

 *.:chrome:. wrote:*   

> l'"undelete" ufficialmente non esiste

 

Bah, però esiste qualcosa chiamato:Linux Ext2fs Undeletion mini-HOWTO.

Ed esiste anche e2undel

Se poi si dice in giro che ext3 è compatibile con ext2...

Comunque sembra proprio che mi sia illuso, ext3 non è affatto "undeletabile": Linux ext3-FAQ.

Di sicuro la prossima partizione "dati sensibili" sarà ext2. Per la root sembra che il tanto vituperato ReiserFS3 permetta di recuperare gran parte del disastro.

----------

## Kernel78

 *xdarma wrote:*   

> Di sicuro la prossima partizione "dati sensibili" sarà ext2. Per la root sembra che il tanto vituperato ReiserFS3 permetta di recuperare gran parte del disastro.

 

[Modalità Elevato Sarcasmo]

Certo, ottima idea usare un fs senza journaling per "dati sensibili". Chissà perché io mi ostino a fare i backup ?

[/Modalità Elevato Sarcasmo]

Tornando seri io stavo pensando di sfruttare un'idea che ho visto in giro ovvero di usare unionfs per effettuare degli snapshot di cartelle importanti (tipo /etc) in modo da poter effettuare un rollback in caso di necessità o di cancellazioni eccessive  :Wink: 

P.S. cmq per evitare rm disastrosi puoi crearti un alias che invece di cancellare sposti in /tmp o dove preferisci in questo modo ti crei un "cestino" alla winzozz. Magari non è il massimo ma ti aiuterebbe in casi di piccole distrazioni.

----------

## federico

O anche alias come mv -i, rm -i e cose del genere!

----------

## Kernel78

 *federico wrote:*   

> O anche alias come mv -i, rm -i e cose del genere!

 

Il problema di questo metodo è il problema della "catena di montaggio", il cervello umano tende a trascurare le differenze in compiti ripetitivi. Un operatore che si vede passare davanti centinaia di componenti uguali avrà problemi a identificarne in breve tempo uno diverso (ovviamente in range accettabili  :Wink:  ), la stessa procedura mentale verrebbe messa in atto quando si sa che la cancellazione richiede un ulteriore conferma, dopo le prima centinaia di volta (ma molto probabilmente anche prima) che per cancellare qualcosa dopo rm si deve premere anche y e invio questo diventa un comportamento istintivo e il cervello si accorge dell'errore (se se ne accorge) troppo tardi quando si cancella anche qualcosa di importante.

Spostare in un "cestino" invece consente un margine di errore visto che se manca /etc te ne accorgi subito e la vai a ripescare immediatamente dal cestino mentre dopo aver dato la conferma sei cmq in una situazione "spiacevole".

----------

## .:chrome:.

 *xdarma wrote:*   

> Bah, però esiste qualcosa

 

a differenza di quanto succede con "altri-sistemi-operativi-poco-seri"  :Laughing:  buona parte dei file system supportati da Linux, quando vuoi cancellare un file, non si limitano a troncare la voce nella FAT: lo cancellano per davvero.

magari non subito, ma prima o poi lo cancellano

quindi... o usi quella roba pochi secondi dopo aver fatto il pasticcio... oppure, come si suol dire, ti attacchi

----------

## cloc3

 *.:chrome:. wrote:*   

> 
> 
> magari non subito, ma prima o poi lo cancellano
> 
> 

 

 :Question: 

cosa vuoi dire?

Lo cancellano  o non lo cancellano?

Io mi aspetto che la rimozione del file avvenga esclusivamente nella tabella delle partizioni.

Sarebbe assurdo che il filesystem si mettesse a ricoprire di zeri il contenuto fisico del file stesso per puro sadismo.

Chiaro che se il file dovesse risultare frammentato, può essere difficile ricostruirlo (la possibilità di farlo, però, sarebbe una qualità positiva, piuttosto che un difetto del filesystem).

Chiaro anche che se lo spazio viene riutilizzato dopo la cancellazione, il recovery è escluso per sempre. Ma questo vale per qualunque filesystem.

(nota: sono solo domande che pongo a me stesso)

----------

## federico

 *Kernel78 wrote:*   

> Spostare in un "cestino" invece consente un margine di errore visto che se manca /etc te ne accorgi subito e la vai a ripescare immediatamente dal cestino mentre dopo aver dato la conferma sei cmq in una situazione "spiacevole".

 

E' vero comunque, magari uno che e' abituato dopo un po' preme "y" senza neanche guardare .)

----------

## .:chrome:.

 *cloc3 wrote:*   

> cosa vuoi dire?
> 
> Lo cancellano  o non lo cancellano?

 

non tutti i file system fanno subito il "commit" delle modifiche

il kernel Linux, in particolare, usa molta memoria: ben più di quella di cui necessitano i programmi correntemente in esecuzione. questo avviene perché le modifiche al file system spesso non vengono scritte immediatamente, ma si aspetta che il processore sia "libero". proprio in base a questo principio, quando cancelli un file, viene dapprima rimosso dalla FAT, e poi cancellato fisicamente.

questo è sempre vero, poi la cancellazione fisica varia da un file system all'altro, ma in linea di principio e con buona approssimazione si può essere certi che la cancellazione vera e propria, avverrà entro il prossimo sync, quindi allo scadere dello slice di tempo, oppure al prossimo shutdown

----------

