เชื่อมโยงไฟล์ที่ถูกลบอีกครั้ง

บางครั้งผู้คนลบไฟล์ที่ไม่ควรทำกระบวนการที่ใช้เวลานานยังคงเปิดไฟล์อยู่และกู้คืนข้อมูลด้วยการจัดการ/proc/<pid>/fd/Nเพียงไม่ดีพอ ยอดเยี่ยมพอที่จะเป็นถ้าคุณสามารถ "ยกเลิก" การลบโดยใช้ตัวเลือกมายากลเพื่อ ln ที่จะช่วยให้คุณเชื่อมโยงไปยังหมายเลข inode (กู้คืนผ่าน lsof)

ฉันไม่พบเครื่องมือ Linux ใด ๆ ที่จะทำเช่นนี้อย่างน้อยก็ด้วย Google อย่างคร่าว ๆ

คุณได้อะไร serverfault

แก้ไข 1: สาเหตุที่ทำให้ไฟล์/proc/<pid>/fd/Nไม่น่ากลัวก็เพราะกระบวนการที่ยังเปิดไฟล์อยู่นั้นยังคงเขียนอยู่ การลบจะลบการอ้างอิงไปยังไอโหนดจากเนมสเปซของระบบไฟล์ สิ่งที่ฉันต้องการคือวิธีการสร้างการอ้างอิงอีกครั้ง

EDIT2: 'debugfs ln' ทำงานได้ แต่ความเสี่ยงสูงเกินไปเนื่องจากจะทำให้ข้อมูลระบบไฟล์ดิบ ไฟล์ที่กู้คืนมานั้นไม่สอดคล้องกันอย่างบ้าคลั่ง จำนวนลิงค์เป็นศูนย์และฉันไม่สามารถเพิ่มลิงก์เข้าไปได้ ฉันแย่กว่านี้เพราะฉันสามารถใช้/proc/<pid>/fd/Nเพื่อเข้าถึงข้อมูลโดยไม่ทำให้ fs ของฉันเสียหาย

ยอดเยี่ยมพอที่จะเป็นถ้าคุณสามารถ "ยกเลิก" การลบโดยใช้ตัวเลือกมายากลเพื่อ ln ที่จะช่วยให้คุณเชื่อมโยงไปยังหมายเลข inode (กู้คืนผ่าน lsof)

ความสุดยอดนี้ได้รับการแนะนำให้รู้จักกับlnในv8.0 (GNU / coreutils) พร้อม-L|--logicalตัวเลือกที่ทำให้เกิดlnการปฏิเสธ/proc/<pid>/fd/<handle>ก่อน ง่าย ๆ

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

เพียงพอที่จะเชื่อมโยงไฟล์ที่ถูกลบใหม่อีกครั้ง

ดูเหมือนคุณจะเข้าใจมากแล้วดังนั้นฉันจะไม่ลงรายละเอียดมากเกินไป มีหลายวิธีในการค้นหา inode และโดยปกติคุณสามารถ cat และ redirect STDOUT debugfsคุณสามารถใช้ เรียกใช้คำสั่งนี้ภายใน:

ln <$INODE> FILENAME

ตรวจสอบให้แน่ใจว่าคุณมีการสำรองข้อมูลของระบบไฟล์ คุณอาจต้องเรียกใช้ fsck หลังจากนั้น ฉันทดสอบสิ่งนี้สำเร็จด้วยไอโหนดที่ยังคงถูกเขียนและมันทำงานเพื่อสร้างฮาร์ดลิงก์ใหม่ไปยังไอโหนดที่ยกเลิกการลงทะเบียน

หากไฟล์ถูกยกเลิกการเชื่อมโยงกับไฟล์ที่ไม่ได้เปิดใน ext3 ข้อมูลจะหายไป ฉันไม่แน่ใจว่าความจริงนี้เป็นอย่างไร แต่ประสบการณ์การกู้คืนข้อมูลส่วนใหญ่ของฉันอยู่ที่ ext2 จากคำถามที่พบบ่อย ext3:

ถาม: ฉันจะกู้คืน (ยกเลิกการลบ) ไฟล์ที่ถูกลบจากพาร์ติชัน ext3 ได้อย่างไร ที่จริงแล้วคุณทำไม่ได้! นี่คือสิ่งที่หนึ่งในนักพัฒนา Andreas Dilger พูดถึง:

เพื่อให้มั่นใจว่า ext3 สามารถเริ่มการเชื่อมต่อได้อย่างปลอดภัยหลังจากเกิดการชนจริง ๆ แล้วมันเป็นศูนย์ตัวชี้บล็อกใน inode ในขณะที่ ext2 เพียงทำเครื่องหมายบล็อกเหล่านี้ว่าไม่ได้ใช้ในบล็อกบิตแมปและทำเครื่องหมาย inode ว่า "ลบ" และออกจากบล็อก พอยน์เตอร์คนเดียว

ความหวังเดียวของคุณคือการ "grep" สำหรับบางส่วนของไฟล์ที่ถูกลบและหวังว่าจะดีที่สุด

นอกจากนี้ยังมีข้อมูลที่เกี่ยวข้องในคำถามนี้:

ฉันเขียนทับไฟล์ขนาดใหญ่ด้วยไฟล์เปล่าบนเซิร์ฟเวอร์ linux ฉันสามารถกู้คืนไฟล์ที่มีอยู่ได้หรือไม่?

วิธี debugfs ตามที่คุณเห็นไม่ทำงานจริง ๆ และไฟล์ของคุณจะถูกลบโดยอัตโนมัติ (เนื่องจากบันทึกประจำวัน) หลังจากรีบูตและที่แย่ที่สุดคุณสามารถทิ้งระบบไฟล์ของคุณซึ่งทำให้ "วงจรการรีบูตแห่งความตาย" Right Solution (TM) คือการยกเลิกการลบในระดับ VFS (ซึ่งมีประโยชน์เพิ่มเติมในการทำงานกับระบบไฟล์ Linux ปัจจุบันทั้งหมด) วิธีการโทรของระบบ (กะพริบ) ถูกยิงทุกครั้งที่ปรากฏใน LKML ดังนั้นวิธีที่ดีที่สุดคือผ่านโมดูล + ioctl

โครงการที่ใช้แนวทางนี้และมีโค้ดที่เล็กและสะอาดพอสมควรคือ fdlink ( https://github.com/pkt/fdlink.gitสำหรับรุ่นที่ทดสอบด้วยเคอร์เนลของ ubuntu maverick) ด้วยหลังจากที่คุณแทรกโมดูล (sudo insmod flink_dev.ko) คุณสามารถทำ "./flinkapp / proc // fd / X / my / link / path" และมันจะทำสิ่งที่คุณต้องการ

คุณยังสามารถใช้ vfs-undelete.sourceforge.net เวอร์ชันฟอร์เวิร์ดพอร์ตที่ใช้งานได้ (และสามารถเชื่อมโยงกับชื่อเดิมได้โดยอัตโนมัติ) แต่รหัสของ fdlink นั้นง่ายกว่าและทำงานได้ดีเช่นกันดังนั้นฉันจึงชอบ

ฉันไม่รู้จะทำสิ่งที่คุณต้องการได้อย่างไร แต่สิ่งที่ฉันจะทำคือ

• เปิดไฟล์ RO จากกระบวนการอื่น
• รอให้กระบวนการเดิมออกจาก
• คัดลอกข้อมูลจาก FD ที่เปิดอยู่ของคุณไปยังไฟล์

ไม่เหมาะอย่างชัดเจน แต่เป็นไปได้ ตัวเลือกอื่นคือเล่นกับ debugfs (โดยใช้linkคำสั่ง) แต่มันก็น่ากลัวในเครื่องที่ใช้งานจริง!

วิ่งเข้าไปในปัญหาเดียวกันวันนี้ สิ่งที่ดีที่สุดที่ฉันสามารถทำได้คือวิ่ง

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

ในเซสชัน tmux / screen จนกว่ากระบวนการจะสิ้นสุด

คำถามที่น่าสนใจ ผู้สัมภาษณ์ถามคำถามเดียวกันกับฉันในการสัมภาษณ์งาน สิ่งที่ฉันบอกเขาก็คือไม่มีวิธีง่ายๆในการทำสิ่งนี้และโดยทั่วไปแล้วไม่คุ้มค่ากับเวลาและความพยายามที่เกี่ยวข้อง ฉันถามเขาในสิ่งที่เขาคิดว่าวิธีแก้ปัญหานี้คือ ....

1. ใช้ lsof เพื่อค้นหาหมายเลข inode บนดิสก์สำหรับกระบวนการเนื่องจากจะยังคงปรากฏแม้ว่าไฟล์จะถูกลบไป ... คีย์คือว่ามันยังคงเปิดอยู่
2. แตกข้อมูลจากระบบไฟล์ตามสิ่งนี้ผ่านดีบักของระบบไฟล์

ใช้Sleuthkit icat

sudo icat /dev/rdisk1s2 5484287 > accidentally_deleted_open_file

ทางออกที่รวดเร็วสำหรับฉันโดยไม่ต้องใช้เครื่องมือข่มขู่:

1) ค้นหากระบวนการ + fd โดยดูโดยตรงใน / proc:

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

2) จากนั้นเทคนิคที่คล้ายกับ @ nickray's โดยมีการpvส่งออกเป็น:

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

คุณอาจต้อง Ctrl-C เมื่อเสร็จแล้ว ( ls /proc/{procnum}/fd/{fdnum}จะบอกคุณว่าไฟล์ไม่มีอยู่อีกต่อไป)) แต่ถ้าคุณรู้ขนาดที่แน่นอนเป็นไบต์คุณสามารถใช้pv -Sเพื่อทำให้มันออกเมื่อถึงจำนวน