6 ms·

Simple (but possibly incomplete) answer: store files you don't want to delete on a ZFS filesystem with snapshots.

marcan_42 6y ago
Better answer: have backups. Fancy filesystems may save you if you use their features properly, but are also hell to do deep data recovery on when something does go wrong. And they are also buggier simply by being more complex.
- mrighele 6y ago
  You should always have backups, but for this specific issue I think that snapshots are much better since you can run them more often (I do a snapshot of my system every hour) and it is probably easier/faster to recover a file from a snapshot than a backup
- lmm 6y ago
  You might be right in the general case, but ZFS is extremely mature and reliable; frankly I trust it more than ext4 at this point.
- bestboy 6y ago
  Using ZFS is no replacement for backups. Still, this would have been a non-issue on a ZFS system: /var/recordings $ ll .zfs/snapshot/ total 72 drwxr-x---+ 7 root root 7 Apr 9 2019 0003/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-26_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-27_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-28_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-29_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 manual-2020-10-05/ /var/recordings $ cp .zfs/snapshot/auto-2020-11-28_00-00/recording-16679.flv recording-16679.flv (every directory/dataset contains an invisible .zfs directory "mounting" the snapshots of the dataset)
- fuzxi 6y ago
  The file he overwrote was the backup, haha. >Given that we already consider it to just be a backup, we currently don’t make any further backups of this data.
  - wizzwizz4 6y ago
    Never mount a backup writeable.
    - sgerenser 6y ago
      How do you make the backups then?
      - wizzwizz4 6y ago
        Well, you can make the backup, but then set the read-only flag on the tarball and never touch it again.
      - deleted 6y ago
        [deleted]
matja 6y ago
Yes, ZFS makes this very easy. It's no problem to snapshot an entire filesystem with billions of files every 5 minutes from cron. Then the OP could have done: zfs-restore-file recording-16679.flv With `zfs-restore-file` as the following script (for example only, I hacked it up in a few minutes) : #!/bin/bash FILE="$1" FULL_PATH=$(realpath "$FILE") DATASET=$(findmnt --target="${FULL_PATH}" --output=SOURCE --noheadings) MOUNT_POINT=$(findmnt --source="${DATASET}" --output=TARGET --noheadings | head -n1) CURRENT_INODE="$(stat -c %i "${FULL_PATH}")" RELATIVE_PATH="$(echo "$FULL_PATH" | sed "s|^${MOUNT_POINT}/||")" # iterate all snapshots of the dataset containing the file, most recent first for SNAPSHOT in $( \ zfs list -t snapshot -H -p -o creation,name "${DATASET}" \ | sort -rn | awk '{print $2}' | cut -d@ -f2 \ ) ; do echo "snapshot $DATASET @ $SNAPSHOT" SNAPSHOT_FILE="${MOUNT_POINT}/.zfs/snapshot/${SNAPSHOT}/${RELATIVE_PATH}" SNAPSHOT_FILE_INODE="$(stat -c %i "${SNAPSHOT_FILE}")" if [ "${SNAPSHOT_FILE_INODE}" == "" ] || [ "${SNAPSHOT_FILE_INODE}" == "${CURRENT_INODE}" ] ; then continue fi echo "found the same named file with a different inode:" ls -l "${SNAPSHOT_FILE}" cp -i "${SNAPSHOT_FILE}" "${FILE}" break done If OP didn't change the inode (overwritten with new content) then you could make another script that compares size/hash of the file, or manually specify a time of a snapshot to restore.

Better answer: have backups. Fancy filesystems may save you if you use their features properly, but are also hell to do deep data recovery on when something does go wrong. And they are also buggier simply by being more complex.

mrighele 6y ago
You should always have backups, but for this specific issue I think that snapshots are much better since you can run them more often (I do a snapshot of my system every hour) and it is probably easier/faster to recover a file from a snapshot than a backup
lmm 6y ago
You might be right in the general case, but ZFS is extremely mature and reliable; frankly I trust it more than ext4 at this point.
bestboy 6y ago
Using ZFS is no replacement for backups. Still, this would have been a non-issue on a ZFS system: /var/recordings $ ll .zfs/snapshot/ total 72 drwxr-x---+ 7 root root 7 Apr 9 2019 0003/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-26_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-27_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-28_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 auto-2020-11-29_00-00/ drwxr-x---+ 7 root root 7 Apr 9 2019 manual-2020-10-05/ /var/recordings $ cp .zfs/snapshot/auto-2020-11-28_00-00/recording-16679.flv recording-16679.flv (every directory/dataset contains an invisible .zfs directory "mounting" the snapshots of the dataset)
fuzxi 6y ago
The file he overwrote was the backup, haha. >Given that we already consider it to just be a backup, we currently don’t make any further backups of this data.
- wizzwizz4 6y ago
  Never mount a backup writeable.
  - sgerenser 6y ago
    How do you make the backups then?
    - wizzwizz4 6y ago
      Well, you can make the backup, but then set the read-only flag on the tarball and never touch it again.
    - deleted 6y ago
      [deleted]

matja 6y ago

Yes, ZFS makes this very easy. It's no problem to snapshot an entire filesystem with billions of files every 5 minutes from cron. Then the OP could have done: zfs-restore-file recording-16679.flv With `zfs-restore-file` as the following script (for example only, I hacked it up in a few minutes) : #!/bin/bash FILE="$1" FULL_PATH=$(realpath "$FILE") DATASET=$(findmnt --target="${FULL_PATH}" --output=SOURCE --noheadings) MOUNT_POINT=$(findmnt --source="${DATASET}" --output=TARGET --noheadings | head -n1) CURRENT_INODE="$(stat -c %i "${FULL_PATH}")" RELATIVE_PATH="$(echo "$FULL_PATH" | sed "s|^${MOUNT_POINT}/||")" # iterate all snapshots of the dataset containing the file, most recent first for SNAPSHOT in $( \ zfs list -t snapshot -H -p -o creation,name "${DATASET}" \ | sort -rn | awk '{print $2}' | cut -d@ -f2 \ ) ; do echo "snapshot $DATASET @ $SNAPSHOT" SNAPSHOT_FILE="${MOUNT_POINT}/.zfs/snapshot/${SNAPSHOT}/${RELATIVE_PATH}" SNAPSHOT_FILE_INODE="$(stat -c %i "${SNAPSHOT_FILE}")" if [ "${SNAPSHOT_FILE_INODE}" == "" ] || [ "${SNAPSHOT_FILE_INODE}" == "${CURRENT_INODE}" ] ; then continue fi echo "found the same named file with a different inode:" ls -l "${SNAPSHOT_FILE}" cp -i "${SNAPSHOT_FILE}" "${FILE}" break done If OP didn't change the inode (overwritten with new content) then you could make another script that compares size/hash of the file, or manually specify a time of a snapshot to restore.