1

summary

How to (relatively painlessly and reliably) {restore, undelete} a file from an ext4 filesystem inside a LVM volume inside a LUKS container, given one knows the fully-qualified path to the file before it was deleted? (Apologies in advance if I'm using incorrect terms--please correct where necessary.)

details

The good news is, it's been years since I accidentally deleted a file that I couldn't easily restore (e.g., from backup). Define some terms for exactness:

  • call the file I {deleted, seek to restore} the target file
  • call the directory/folder in which the target file formerly resided the target dir
  • call the partition {on which the target file formerly resided, to which I seek to restore the target file} the target partition

The bad news is,

  • The last time, the target partition was "simple ext4": i.e., no encryption or other management.
  • This time, the target partition is the one with name=LVM2_crypt-home from the following lsblk table:

    NAME                  MAJ:MIN   SIZE  TYPE  MOUNTPOINT
    sda                     8:0   465.8G  disk
    ├─sda1                  8:1    16.6G  part
    ├─sda2                  8:2    97.7G  part
    ├─sda3                  8:3     500M  part  /boot
    ├─sda4                  8:4       1K  part
    └─sda5                  8:5     351G  part
      └─LVM2_crypt        254:0     351G  crypt
        ├─LVM2_crypt-swap 254:1     3.9G  lvm
        ├─LVM2_crypt-root 254:2      20G  lvm   /
        └─LVM2_crypt-home 254:3   327.1G  lvm   /home
    

I believe I recall how to recover a file from a simple partition using extundelete: see procedure below. What I'd like to know is

  1. Will the same or similar procedure work for a managed+encrypted partition? If not same, what needs added, modified, or deleted?
  2. Is there a more reliable tool (than extundelete) for this usecase? If so, what is its procedure for this usecase?

simple-partition procedure

My procedure last time--for the "simple" ext4 partition--used extundelete like the following (bash) example:

  1. Read info extundelete and (the all-too-meager) extundelete doc (scroll down to heading=Documentation). Note that it can handle usecases other than that illustrated here, e.g., restore all deleted files from a partition.
  2. Specify the target file:

    1. define its fully-qualified path TARGET_FQP, remembering not to use ~:

      # CHANGE FOR YOUR USECASE!
      TARGET_FQP="${HOME}/video/greatest_movie_ever.mp4"
      echo "TARGET_FQP='${TARGET_FQP}'"
      
    2. define its directory/folder (which we'll assume is on the same (target) partition as the target file):

      TARGET_DIR="$(dirname "${TARGET_FQP}")"
      echo "TARGET_DIR='${TARGET_DIR}'"
      
    3. define its filename (for use below)

      TARGET_FN="$(basename "${TARGET_FQP}")"
      echo "TARGET_FN='${TARGET_FN}'"
      
  3. Identify the target partition TARGET_PART and its mount point TARGET_MP from your target dir:

    TARGET_PART="$(df --output=source "${TARGET_FQP}" | tail -1)"
    echo "TARGET_PART='${TARGET_PART}'"
    TARGET_MP="$(df --output=target "${TARGET_FQP}" | tail -1)"
    echo "TARGET_MP='${TARGET_MP}'"
    
  4. Open your shell of choice (in your terminal of choice) with a current working directory (CWD) such that

    • CWD is on a partition other than the target. (Get information about your partitions using lsblk, fdisk or your tool of choice.)
    • extundelete will restore any file it finds (if any) to a CWD subdir name=RECOVERED_FILES, so I'm guessing that, if you already have one with that name, you want to move it. (If you know how to override that, please lemme know. IIRC, --restore-directory does not do this.)
  5. Remount the target partition read-only:

    mount --options remount,ro --source "${TARGET_PART}"
    
  6. Run extundelete:

    date # because if this runs too long, you'll wanna give up
    extundelete --restore-file "${TARGET_FQP}" "${TARGET_PART}"
    
  7. Check the restored file:

    SAVED_RELPATH="./RECOVERED_FILES/${TARGET_FN}"
    echo '(hopefully) restored file @'
    ls -al "${SAVED_RELPATH}"
    
  8. Presuming the restored file @ SAVED_RELPATH is what you want, you can either remount TARGET_PART read/write and move it there, or (what I usually do)

    1. move the restored file to an external backup
    2. reboot the PC containing TARGET_PART
    3. copy the restored file from the backup to TARGET_DIR

Your corrections or improvements are welcome.

  • Have you succeeded? – petRUShka Apr 29 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.