Ricollegare un file eliminato

A volte le persone eliminano i file che non dovrebbero, un processo di lunga durata ha ancora il file aperto e il recupero dei dati catting /proc/<pid>/fd/Nnon è abbastanza eccezionale. Sarebbe davvero fantastico se tu potessi "annullare" l'eliminazione eseguendo qualche opzione magica su ln che ti consentirebbe di ricollegarti al numero di inode (recuperato tramite lsof).

Non riesco a trovare alcun strumento Linux per fare questo, almeno con Google Google.

Che cosa hai, serverfault?

EDIT1: Il motivo per cui catturare il file /proc/<pid>/fd/Nnon è abbastanza eccezionale è perché il processo che ha ancora il file aperto sta ancora scrivendo su di esso. Una cancellazione rimuove il riferimento all'inode dallo spazio dei nomi del filesystem. Quello che voglio è un modo per ricreare il riferimento.

EDIT2: 'debugfs ln' funziona ma il rischio è troppo alto poiché blocca i dati grezzi del filesystem. Il file recuperato è anche pazzo incoerente. Il conteggio dei collegamenti è zero e non riesco ad aggiungere collegamenti ad esso. Sto peggio in questo modo poiché posso semplicemente usare /proc/<pid>/fd/Nper accedere ai dati senza corrompere il mio fs.

Sarebbe davvero fantastico se tu potessi "annullare" l'eliminazione eseguendo qualche opzione magica su ln che ti permetterebbe di ricollegarti al numero di inode (recuperato tramite lsof).

Questa meraviglia è stata introdotta lnin v8.0 (GNU / coreutils) con l' -L|--logicalopzione che provoca lnuna /proc/<pid>/fd/<handle>prima deduzione . Quindi un semplice

ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file

è sufficiente per ricollegare un file eliminato.

Sembra che tu abbia già capito molto, quindi non entrerò nei dettagli in eccesso. Esistono diversi metodi per trovare l'inode e di solito puoi cat e reindirizzare STDOUT. È possibile utilizzare debugfs. Esegui questo comando in:

ln <$INODE> FILENAME

Assicurati di disporre di backup del filesystem. Probabilmente dovrai eseguire un fsck in seguito. L'ho testato con successo con un inode ancora in fase di scrittura e funziona per creare un nuovo collegamento reale a un inode con riferimenti.

Se il file non è collegato con un file non aperto in ext3, i dati vengono persi. Non sono sicuro di quanto sia sempre vero, ma la maggior parte della mia esperienza di recupero dati è con ext2. Dalle FAQ ext3:

D: Come posso recuperare (ripristinare) i file cancellati dalla mia partizione ext3? In realtà, non puoi! Questo è quanto ha affermato uno degli sviluppatori, Andreas Dilger:

Al fine di garantire che ext3 possa riprendere in modo sicuro un unlink dopo un crash, in realtà azzera i puntatori di blocco nell'inode, mentre ext2 contrassegna questi blocchi come inutilizzati nelle bitmap del blocco e contrassegna l'inode come "eliminato" e lascia il blocco solo puntatori.

La tua unica speranza è quella di "grep" per parti dei tuoi file che sono stati eliminati e sperare per il meglio.

Ci sono anche informazioni rilevanti in questa domanda:

Ho sovrascritto un file di grandi dimensioni con uno vuoto su un server Linux. Posso recuperare il file esistente?

il modo di debug come hai visto non funziona davvero e nella migliore delle ipotesi il tuo file verrà eliminato automaticamente (a causa del journal) dopo il riavvio e nella peggiore delle ipotesi puoi eliminare il tuo filesystem risultante in "riavvio del ciclo della morte". La soluzione giusta (TM) è quella di eseguire il ripristino nel livello VFS (che ha anche il vantaggio di lavorare praticamente con tutti i filesystem Linux attuali). Il modo di chiamata di sistema (flink) è stato abbattuto ogni volta che è apparso in LKML, quindi il modo migliore è attraverso un modulo + ioctl.

Un progetto che implementa questo approccio e ha un codice ragionevolmente piccolo e pulito è fdlink ( https://github.com/pkt/fdlink.git per una versione testata con il kernel di Ubuntu Maverick). Con esso, dopo aver inserito il modulo (sudo insmod flink_dev.ko) puoi semplicemente fare "./flinkapp / proc // fd / X / my / link / path" e farà esattamente quello che vuoi.

Puoi anche usare una versione con port forwarding di vfs-undelete.sourceforge.net che funziona (e può anche ricollegarsi automaticamente al nome originale), ma il codice di fdlink è più semplice e funziona altrettanto bene, quindi è la mia preferenza.

Non so come fare esattamente quello che vuoi, ma quello che vorrei fare è:

• Apri il file RO da un altro processo
• Attendere il termine del processo originale
• Copia i dati dall'FD aperto in un file

Non ideale, ovviamente, ma possibile. L'altra opzione è quella di giocare con debugfs (usando il linkcomando), ma è un po 'spaventoso su una macchina di produzione!

Ho incontrato lo stesso problema oggi. Il meglio che ho potuto inventare è correre

% tail -n +0 -f /proc/<pid>/fd/<fd> /path/to/deleted_file

in una sessione tmux / screen fino al termine del processo.

Domanda interessante. Un intervistatore mi ha posto la stessa domanda in un colloquio di lavoro. Quello che gli ho detto è che non c'era un modo semplice per farlo e in generale non valeva il tempo e gli sforzi necessari. Gli ho chiesto quale pensava fosse la soluzione a questo problema ...

1. Usa lsof per trovare il numero di inode sul disco per il processo in quanto verrà visualizzato anche se il file è stato eliminato ... la chiave è che è ancora aperto.
2. Estrarre le informazioni dal filesystem in base a ciò tramite un debugger del filesystem.

Usa Sleuthkit icat.

sudo icat /dev/rdisk1s2 5484287 > accidentally_deleted_open_file

La soluzione rapida che ha funzionato per me, senza strumenti intimidatori:

1) trova il processo + fd guardando direttamente in / proc:

ls -al /proc/*/fd/* 2>/dev/null | grep {filename}

2) Quindi una tecnica simile a quella di @ nickray, con l'aggiunta di pv:

tail -c +0 -f /proc/{procnum}/fd/{fdnum} | pv -s {expectedsize} > {recovery_filename}

Al termine potrebbe essere necessario Ctrl-C ( ls /proc/{procnum}/fd/{fdnum}ti dirà che il file non esiste più)), ma se conosci la dimensione esatta in byte, puoi usarlo pv -Sper uscire quando viene raggiunto il conteggio.