Tập tin trống rỗng một cách bí ẩn. Lựa chọn để phục hồi?


9

Tôi đã thấy một số bài viết về việc khôi phục các tập tin bị xóa, nhưng tình huống này là khác nhau. Vợ tôi có một tập tin tên là Journal.odt, trong đó cô ấy lưu giữ rất nhiều thông tin cá nhân quan trọng như những kỷ niệm đặc biệt về những đứa trẻ của chúng tôi. Một ngày khác, khi cô cố gắng mở nó trong OpenOffice, nó đã phàn nàn về định dạng này. Tôi đã đánh cô ấy hủy bỏ và trở ra. Khi tôi cattập tin nó hoàn toàn trống rỗng. lscho biết tệp là 0 byte.

Nếu cô ấy vô tình chọn tất cả các văn bản trong tệp, nhấn backspace và lưu nó thì vẫn sẽ có thông tin meta OpenOffice trong tệp.

Tôi ngay lập tức tắt máy tính xách tay của cô ấy xuống để tránh thực hiện thêm bất kỳ thay đổi nào cho đĩa cho đến khi tôi có thể nghĩ ra một cái gì đó để làm.

Tôi đã thực hiện một số điều phức tạp trong quá khứ như sử dụng ddđể khôi phục văn bản thô khỏi đĩa nhưng tôi không biết phải làm gì ở đây. Vì các tập tin odt không phải là văn bản phẳng, tôi không thể chuyển toàn bộ đĩa qua grep.

Bất kỳ đề xuất sẽ được đánh giá rất cao.

Ngoài ra nếu bất cứ ai có cái nhìn sâu sắc về những gì có thể đã sai, tôi rất thích nghe nó.

Cảm ơn


1
Sẽ khác nếu tệp vô tình bị xóa hoặc một cái gì đó, nhưng khi trong trình soạn thảo văn bản, v.v. lưu tệp thường ghi "tại chỗ" một cách hiệu quả xóa sạch mọi thứ có thể được phục hồi bằng phục hồi sức mạnh pháp y. Sẽ tốt hơn nếu bạn không tắt hệ thống ngay lập tức, tôi cá rằng một vài lần nhấn control + z (chức năng "hoàn tác" trong Open Office) sẽ khắc phục được sự cố.
Tim

@Tim Tôi thấy quan điểm của bạn, nhưng không may là tập tin đã bị xóa ngày trước. Lần sửa đổi cuối cùng trên tập tin là một vài ngày trước đó. Theo mô tả của tôi khi cô ấy mở nó trong OO thì nó đã trống rỗng. Cảm ơn mặc dù.
jcbwlkr

2
Không cố gắng đánh bại một con ngựa chết, hoặc đá một người đàn ông khi anh ta xuống, nhưng tôi nghi ngờ kinh nghiệm này sẽ giúp bạn xem xét một giải pháp dự phòng. Hãy xem "Sao lưu Areca" cho một ứng dụng sao lưu đơn giản, tương thích với Linux.
Tim

Có lẽ đĩa đầy? Kiểm tra vớidf -h
jippie

@Tim Nếu tệp là 0 byte, thì đó không phải là tài liệu OO; Ctrl+Zsẽ không làm gì cả, vì tập tin không được lưu như OO. @ Jacobwalker0814 Tệp ODT là tệp zip, vì vậy các công cụ khôi phục như testdisk có cơ hội tìm thấy chúng; nhưng không có gì đảm bảo, và ngay cả khi dữ liệu vẫn còn đó, bạn có thể phải lội qua rất nhiều tệp zip khác. Và cho tương lai, làm sao lưu!
Gilles 'SO- ngừng trở nên xấu xa'

Câu trả lời:


3

Nếu bạn đang sử dụng hệ thống tệp ext3, hãy thử theo dõi HOWTO của Carlo Wood

Trong vài từ

  • Sử dụng ext3grep $ IMAGE --ls --inode 2 | grep your_file để tìm tệp bạn đang tìm (trong đó $ IMAGE là phân vùng của bạn, ví dụ / dev / sda2)
  • Tìm khối hệ thống tệp chứa tạp chí của không gian chưa phân bổ.
  • Tìm tất cả các khối mô tả tạp chí đã được tìm thấy trước đây.
  • Sao chép khối bằng dd.
  • Chỉnh sửa tập tin để xóa các số 0 ở cuối.
  • cat tập tin bất cứ nơi nào bạn muốn

Từ nguồn:

"Ví dụ phục hồi chương thủ công

Trong ví dụ sau, chúng tôi sẽ tự phục hồi một tệp nhỏ. Chỉ có đầu ra một phần được đưa ra để tiết kiệm không gian và làm cho ví dụ dễ đọc hơn.

Sử dụng ext3grep $ IMAGE --ls --inode, chúng tôi tìm thấy tên của tệp mà chúng tôi muốn khôi phục:

$ ext3grep $ IMAGE --ls --inode 2 | grep carlo 3 end d 195456 D 1202352103 Thu ngày 7 tháng 2 03:41:43 2008 drwxr-xr-x carlo

$ ext3grep $ IMAGE --ls --inode 195456 | grep 'bin $' | đầu -n 1 34 35 d 309540 D 1202352104 Thu ngày 7 tháng 2 03:41:44 2008 drwxr-xr-x bin

$ ext3grep $ IMAGE --ls --inode 309540 | grep start_azureus 9 10 r 309631 D 1202351093 Thu ngày 7 tháng 2 03:24:53 2008 rrwxr-xr-x start_azureus

Rõ ràng, inode 309631 bị xóa và chúng tôi không có số khối cho tệp này:

$ ext3grep $ IMAGE --print --inode 309631 [...] Inode là Unallocated Nhóm: 19 Thế hệ Id: 2771183319 uid / gid: 1000/1000 chế độ: rrwxr-xr-x size: 0 num liên kết: 0 sector: 0 (-> 0 khối gián tiếp).

Inode Times: Truy cập: 1202350961 = Thu ngày 7 tháng 2 03:22:41 2008 Tập tin đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Inode Đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Thời gian xóa: 1202351093 = Thu Ngày 7 tháng 2 03:24:53 2008

Khối trực tiếp:

Do đó, chúng tôi sẽ cố gắng tìm kiếm một bản sao cũ hơn của nó trong tạp chí. Đầu tiên, chúng tôi tìm thấy khối hệ thống tệp có chứa nút này:

$ ext3grep $ IMAGE --inode-to-block 309631 | grep cư trú Inode 309631 nằm trong khối 622598 tại offset 0xf00.

Sau đó, chúng tôi tìm thấy tất cả các mô tả tạp chí tham chiếu khối 622598:

$ ext3grep $ NGAY 4382137 6672 4382138 7536 4382139 7984 4382140 8931

Điều này có nghĩa là giao dịch với số thứ tự 4381294 có một bản sao của khối 622598 trong khối 26582, v.v. Số thứ tự lớn nhất, ở dưới cùng, phải là dữ liệu cuối cùng được ghi vào đĩa và do đó, khối 8931 phải giống với khối hiện tại 622598. Để tìm bản sao không bị xóa cuối cùng, người ta phải bắt đầu ở dưới cùng và làm việc trở lên

Nếu bạn cố in một khối như vậy, ext3grep nhận ra rằng đó là một khối từ bảng inode và sẽ in nội dung của tất cả 32 nút trong đó. Tuy nhiên, chúng tôi chỉ muốn thấy inode 309631; vì vậy chúng tôi sử dụng một grep thông minh:

$ ext3grep $ IMAGE --print --block 8931 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Id thế hệ: 2771183319 uid / gid: chế độ 1000/1000: rrwxr-xr-x size: 0 num liên kết: 0 sector: 0 (-> 0 khối gián tiếp).

Inode Times: Truy cập: 1202350961 = Thu ngày 7 tháng 2 03:22:41 2008 Tập tin đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Inode Đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Thời gian xóa: 1202351093 = Thu Ngày 7 tháng 2 03:24:53 2008

Khối trực tiếp:

Điều này thực sự giống như chúng ta đã thấy trong khối 622598. Tiếp theo chúng ta xem xét các số thứ tự nhỏ hơn cho đến khi chúng ta tìm thấy một số có thời gian Xóa 0. Cái đầu tiên mà chúng ta tìm thấy (từ dưới lên) là khối 6073:

$ ext3grep $ IMAGE --print --block 6073 | grep -A15 'Inode 309631' -------------- Inode 309631 ----------------------- Id thế hệ: 2771183319 uid / gid: chế độ 1000/1000: rrwxr-xr-x size: 40 num liên kết: 1 sector: 8 (-> 0 khối gián tiếp).

Inode Times: Truy cập: 1202350961 = Thu ngày 7 tháng 2 03:22:41 2008 Tập tin đã sửa đổi: 1189688692 = Thu ngày 13 tháng 9 15:04:51 2007 Inode Đã sửa đổi: 1189688692 = Thu ngày 13 tháng 9 15:04:51 2007 Thời gian xóa: 0

Khối trực tiếp: 645627

Ở trên là tự động và có thể được thực hiện nhanh hơn nhiều với tùy chọn dòng lệnh --show-tạp chí-inodes. Tùy chọn này sẽ tìm thấy khối mà inode thuộc về, sau đó tìm tất cả các bản sao của khối đó trong tạp chí và sau đó chỉ in các nút được yêu cầu từ mỗi khối này (mỗi khối chứa 32 nút, như bạn biết), loại bỏ các bản sao :

$ ext3grep $ IMAGE --show-Tạp chí-inodes 309631 Số lượng nhóm: 75 Khối nhật ký tối thiểu / tối đa: 1115/35026 Đang tải mô tả tạp chí ... đã thực hiện giao dịch Tạp chí 4381435, một số khối dữ liệu có thể bị mất trong giao dịch này. Số lượng mô tả trong tạp chí: 30258; Số thứ tự tối thiểu / tối đa: 4379495/4332264 Bản sao của inode 309631 được tìm thấy trong tạp chí:

-------------- Inode 309631 ----------------------- Id thế hệ: 2771183319 uid / gid: 1000/1000 chế độ: rrwxr-xr-x size: 0 num liên kết: 0 sector: 0 (-> 0 khối gián tiếp).

Inode Times: Truy cập: 1202350961 = Thu ngày 7 tháng 2 03:22:41 2008 Tập tin đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Inode Đã sửa đổi: 1202351093 = Thu ngày 7 tháng 2 03:24:53 2008 Thời gian xóa: 1202351093 = Thu Ngày 7 tháng 2 03:24:53 2008

Khối trực tiếp:

-------------- Inode 309631 ----------------------- Id thế hệ: 2771183319 uid / gid: 1000/1000 chế độ: rrwxr-xr-x size: 40 num liên kết: 1 sector: 8 (-> 0 khối gián tiếp).

Inode Times: Truy cập: 1202350961 = Thu ngày 7 tháng 2 03:22:41 2008 Tập tin đã sửa đổi: 1189688692 = Thu ngày 13 tháng 9 15:04:51 2007 Inode Đã sửa đổi: 1189688692 = Thu ngày 13 tháng 9 15:04:51 2007 Thời gian xóa: 0

Khối trực tiếp: 645627

Các tập tin thực sự nhỏ: chỉ có một khối. Chúng tôi sao chép khối này với dd như hình trước:

$ dd if = $ IMAGE bs = 4096 đếm = 1 Skip = 645627 of = block.645627 bản ghi 1 + 0 trong 1 + 0 bản ghi ra 4096 byte (4,1 kB) được sao chép, 0,0166104 giây, 247 kB / s

và sau đó chỉnh sửa tệp để xóa các số 0 ở cuối hoặc sao chép 40 byte đầu tiên (kích thước đã cho của tệp):

$ dd if = block.645627 bs = 1 Count = 40 of = start_azureus 40 + 0 bản ghi trong 40 + 0 bản ghi trong 40 byte (40 B) được sao chép, 0,000105394 giây, 380 kB / s

$ cat start_azureus cd / usr / src / azureus / azureus ./azureus &

Đã phục hồi! "


Tôi rất thích nhìn vào đó nhưng liên kết dường như đã chết.
jcbwlkr

3
Dường như không chết đối với tôi.
Ông Lister

vâng, tôi cũng có thể truy cập nó.
java_xof

Bây giờ nó hoạt động tốt. Nó chắc chắn không sớm hơn. Ai biết? Cảm ơn, java. Tôi sẽ xem xét nó.
jcbwlkr

Không có vấn đề gì, hy vọng điều này sẽ giúp bạn, không xúc phạm nhưng tôi biết điều gì đó về vợ tương tác <-> máy tính;)
java_xof

2

Hãy thử testdisk và photorec , nhưng cách tôi hiểu bài viết của bạn có lẽ là cách khó để tìm hiểu giá trị của các bản sao lưu thông thường. Ngoài ra, bạn có thể muốn khởi động từ CD để ngăn đĩa cứng bị thay đổi hơn nữa. Cá nhân tôi thích System Cứu đĩa cho việc này, nhưng nó chủ yếu dựa trên dòng lệnh.


1

Sử dụng Caine một bản phân phối linux đặc biệt cho pháp y kỹ thuật số. Đó là rất nhiều công cụ để phục hồi tập tin và đĩa cứng.


Cảm ơn. Tôi sẽ xem xét bản phân phối đó và xem nó có gì không. Bạn có bất kỳ đề xuất nào về các công cụ cụ thể hoặc các cách để tiếp cận vấn đề không? Vấn đề ở đây là tập tin không bị xóa mà nhiều công cụ dường như giải quyết; nó chỉ mất nội dung của nó.
jcbwlkr

1
Open Office đôi khi tạo một tập tin ẩn chứa tài liệu đã lưu trước đó. Nếu may mắn, bạn có thể thử khôi phục nó bằng cách sử dụng ví dụ "extundelete" hoặc "testdisk" cssecurity.org/wiki/TestDisk
PsyStyle

Hãy tìm trong ~ / .openoffice.org / 3 / user / backup / hoặc ~ / .libreoffice.org / 3 / user / backup / Tôi đã viết một tập lệnh để xóa các thư mục này để những thứ nhạy cảm tôi đã xóa vẫn không có ở đó.
Joe
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.