Xem lại một tập tin đã xóa

Đôi khi mọi người xóa các tệp mà họ không nên, một quy trình chạy dài vẫn mở tệp và khôi phục dữ liệu bằng cách trích dẫn /proc/<pid>/fd/Nchỉ là không đủ tuyệt vời. Đủ tuyệt vời sẽ là nếu bạn có thể "hoàn tác" việc xóa bằng cách chạy một số tùy chọn ma thuật để cho phép bạn liên kết lại với số inode (được phục hồi thông qua lsof).

Tôi không thể tìm thấy bất kỳ công cụ Linux nào để làm điều này, ít nhất là với Google Googling.

Bạn có gì, serverfault?

EDIT1: Lý do trích dẫn tệp từ /proc/<pid>/fd/Nkhông đủ tuyệt vời là vì quá trình vẫn mở tệp vẫn đang ghi vào đó. Việc xóa sẽ xóa tham chiếu đến inode khỏi không gian tên hệ thống tập tin. Những gì tôi muốn là một cách để tạo lại tài liệu tham khảo.

EDIT2: 'debugfs ln' hoạt động nhưng rủi ro quá cao vì nó đóng băng dữ liệu hệ thống tập tin thô. Các tập tin phục hồi cũng điên không nhất quán. Số lượng liên kết bằng không và tôi không thể thêm liên kết đến nó. Tôi tệ hơn theo cách này vì tôi chỉ có thể sử dụng /proc/<pid>/fd/Nđể truy cập dữ liệu mà không làm hỏng fs của mình.

Đủ tuyệt vời sẽ là nếu bạn có thể "hoàn tác" việc xóa bằng cách chạy một số tùy chọn ma thuật để cho phép bạn liên kết lại với số inode (được phục hồi thông qua lsof).

Điều tuyệt vời này đã được giới thiệu lntrong v8.0 (GNU / coreutils) với -L|--logicaltùy chọn gây ra lnsự thiếu sót /proc/<pid>/fd/<handle>trước tiên. Thật đơn giản

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

là đủ để xem lại một tập tin bị xóa.

Có vẻ như bạn đã hiểu rất nhiều, vì vậy tôi sẽ không đi sâu vào chi tiết. Có một số phương pháp để tìm inode và bạn thường có thể cat và chuyển hướng STDOUT. Bạn có thể sử dụng debugfs. Chạy lệnh này trong:

ln <$INODE> FILENAME

Hãy chắc chắn rằng bạn có bản sao lưu của hệ thống tập tin. Bạn có thể sẽ cần phải chạy một fsck sau đó. Tôi đã thử nghiệm điều này thành công với một nút vẫn đang được viết và nó hoạt động để tạo ra một liên kết cứng mới đến một nút bị hủy đăng ký.

Nếu tệp không được liên kết với tệp chưa mở trong ext3, dữ liệu sẽ bị mất. Tôi không chắc điều này đúng như thế nào nhưng hầu hết trải nghiệm phục hồi dữ liệu của tôi là với ext2. Từ câu hỏi thường gặp về ext3:

H: Làm cách nào tôi có thể khôi phục (hủy xóa) các tệp đã xóa khỏi phân vùng ext3 của mình? Thật ra, bạn không thể! Đây là những gì một trong những nhà phát triển, Andreas Dilger, nói về nó:

Để đảm bảo ext3 có thể khôi phục lại một liên kết một cách an toàn sau khi gặp sự cố, nó thực sự loại bỏ các con trỏ khối trong inode, trong khi ext2 chỉ đánh dấu các khối này là không được sử dụng trong bitmap khối và đánh dấu inode là "bị xóa" và rời khỏi khối con trỏ một mình.

Hy vọng duy nhất của bạn là "grep" cho các phần của tệp đã bị xóa và hy vọng điều tốt nhất.

Cũng có thông tin liên quan trong câu hỏi này:

Tôi ghi đè lên một tệp lớn với một tệp trống trên máy chủ linux. Tôi có thể khôi phục các tập tin hiện có?

cách gỡ lỗi như bạn thấy không thực sự hoạt động và tốt nhất là tệp của bạn sẽ tự động bị xóa (do tạp chí) sau khi khởi động lại và tệ nhất là bạn có thể rác hệ thống tệp của mình dẫn đến "chu kỳ khởi động lại cái chết". Giải pháp đúng (TM) là thực hiện khôi phục ở cấp độ VFS (cũng có thêm lợi ích khi làm việc với tất cả các hệ thống tệp Linux hiện tại). Cách gọi hệ thống (flink) đã bị bắn hạ mỗi khi nó xuất hiện trong LKML, vì vậy cách tốt nhất là thông qua một mô-đun + ioctl.

Một dự án thực hiện phương pháp này và có mã nhỏ và hợp lý là fdlink ( https://github.com/pkt/fdlink.git cho một phiên bản được thử nghiệm với kernel của ub Ubuntu maverick). Với nó, sau khi bạn chèn mô-đun (sudo insmod flink_dev.ko), bạn có thể thực hiện "./flinkapp / Proc // fd / X / my / link / path" và nó sẽ thực hiện chính xác những gì bạn muốn.

Bạn cũng có thể sử dụng phiên bản chuyển tiếp của vfs-undelete.sourceforge.net cũng hoạt động (và cũng có thể tự động chuyển lại tên gốc), nhưng mã của fdlink đơn giản hơn và nó cũng hoạt động tốt, vì vậy đó là sở thích của tôi.

Tôi không biết làm thế nào để làm chính xác những gì bạn muốn, nhưng những gì tôi sẽ làm là:

• Mở tệp RO từ quy trình khác
• Đợi quá trình ban đầu để thoát
• Sao chép dữ liệu từ FD mở của bạn vào một tệp

Không lý tưởng, rõ ràng, nhưng có thể. Tùy chọn khác là chơi xung quanh với debugfs (sử dụng linklệnh), nhưng điều đó thật đáng sợ trên một máy sản xuất!

Ran vào cùng một vấn đề ngày hôm nay. Điều tốt nhất tôi có thể nghĩ ra là chạy

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

trong một phiên tmux / màn hình cho đến khi quá trình kết thúc.

Câu hỏi thú vị. Một người phỏng vấn đã hỏi tôi câu hỏi tương tự trong một cuộc phỏng vấn xin việc. Những gì tôi nói với anh ta là không có cách nào dễ dàng để làm điều này và nói chung là không xứng đáng với thời gian và nỗ lực liên quan. Tôi đã hỏi anh ấy những gì anh ấy nghĩ giải pháp cho vấn đề này là ....

1. Sử dụng lsof để tìm số inode trên đĩa cho quá trình vì nó vẫn sẽ xuất hiện ngay cả khi tệp đã bị xóa ... điều quan trọng là nó vẫn đang mở.
2. Trích xuất thông tin từ hệ thống tập tin dựa trên điều này thông qua trình gỡ lỗi hệ thống tập tin.

Sử dụng iuth Sleuthkit .

sudo icat /dev/rdisk1s2 5484287 > accidentally_deleted_open_file

Giải pháp nhanh chóng hiệu quả với tôi mà không cần các công cụ đáng sợ:

1) tìm quá trình + fd bằng cách xem trực tiếp trong / Proc:

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

2) Sau đó, một kỹ thuật tương tự như @ nickray, với pvném vào:

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

Bạn có thể cần Ctrl-C khi hoàn tất ( ls /proc/{procnum}/fd/{fdnum}sẽ cho bạn biết rằng tệp không còn tồn tại)), nhưng nếu bạn biết kích thước chính xác theo byte, bạn có thể sử dụng pv -Sđể làm cho nó thoát khi đạt được số đếm.