ext4, extundelete. OH NO

[blobfish]

I did it! I was deleting some misc file in my home folder and my video folder was selected and I didn't realize it. I took me about 15 seconds to realize it and run across the room and kill my server. Plenty of damage has been done. I got the server booted back up and started exploring extundelete. My problem is: I interrupted the delete process and my ext4 journal is corrupt. What is actually still on the drive vs what extundelete says has been removed are badly out of sync. All information on extundelete explicitly state 'do not write to the drive', so I am afraid of letting fsck fix the journal. It looks like extundelete will take an external journal, so I am now researching if/how I can make an fixed, external journal of the drive. Any advice?

Submitting post went about as well as everything else this morning. Sorry if this is double posted.

[GreyGeek]

Advice, you ask?

Above all, DO NOT write to the drive, but you knew that already. Copy what you can to the drive you are running extundelete from, or another drive, then try unextdelete, which will store recovered files into the RECOVERED_FILES subdirectory. The corrupted drive is not mounted when you run extundelete so there is no chance of extundelete writing anything to it.

After extundelete has done what it can, THEN run fsck on the drive and then retry extundelete. It might pick up more stuff.

Here's my real advice: After you've recovered everything you can, and backed up the rest to another HD, reformat that sever with Btrfs. IF you had formatted your server with Btrfs and kept regular snapshots, or at least made a snapshot BEFORE you began your deleting spree, all you would have had to do is take 3 minutes to roll back to your snapshot and you'd have everything the way it was before the spree began. A snapshot backup, like any other, is not complete until it has been sent to a backup server which has received it. (Btrfs' send & receive commands)

[blobfish]

Advice, you ask?

Above all, DO NOT write to the drive, but you knew that already. Copy what you can to the drive you are running extundelete from, or another drive, then try unextdelete, which will store recovered files into the RECOVERED_FILES subdirectory. The corrupted drive is not mounted when you run extundelete so there is no chance of extundelete writing anything to it.

After extundelete has done what it can, THEN run fsck on the drive and then retry extundelete. It might pick up more stuff.

Thanks for the response. The problem is this is my media server and I don't have destination hard drive space without purchasing more hard drive/s. Spending money is always my last choice. The fact that I interrupted the delete process and corrupted the journal, makes me think maybe unextdelete is not the right tool for the job. I am currently researching others.

Here's my real advice: After you've recovered everything you can, and backed up the rest to another HD, reformat that sever with Btrfs. IF you had formatted your server with Btrfs and kept regular snapshots, or at least made a snapshot BEFORE you began your deleting spree, all you would have had to do is take 3 minutes to roll back to your snapshot and you'd have everything the way it was before the spree began. A snapshot backup, like any other, is not complete until it has been sent to a backup server which has received it. (Btrfs' send & receive commands)

I knew my whole operation was pretty amateurish. I don't blame anybody but myself, accept I will complain about dolphin's automatic selection of folders as I navigate 'up' my filesystem. How big are the btrfs snapshots compared to the data?

[vinnywright]

How big are the btrfs snapshots compared to the data?

the initial snapshot only takes up a small amount of meta data space but can grow in size as you remove things from the original source and it dose not gain the new files you add to the source just as a snapshot their are wayes to add to the snapshot ,,,,fore more look hear https://www.kubuntuforums.net/showth...l=1#post418067

VINNY

[GreyGeek]

What Vinny says ....
When you first create a snapshot, say of @home, as @home_snapshot, all it has in it are meta data about the files in /home. As you add, delete or change a file or folder the Copy on Write (CoW) copies the original file to the snapshot. If an existing file is not modified its snapshot --rflink is unchanged. The more you add, delete or change in /home the bigger @home_snapshot becomes. Other activities using btrfs tools also cause snapshots to expand. Given enough time a snapshot can get close to the size of the subvolume from which it was made. New snapshots are often created using the "-r" (read only) switch and are sent to an external storage device using the btrfs send & receive commands. Ditto with incremental send & receive (using the -p switch). After a new snapshot is made the oldest pair (@_snapshot and @home_snapshot) are often deleted using the "btrfs sub delete -C /mnt/snapshots/@_snapshot" command, etc... Generally, less than half a dozen pair of snapshots per subvolume are kept around.

[jlittle]

Here's my real advice: ... reformat that server with Btrfs ... all you would have had to do is ... to roll back to your snapshot ...

Good advice. But you don't have to roll back to a snapshot ... just go into it (with dolphin) and your files are still there, if your files are older than the latest snapshot. Your snapshot might be months old, but if the files existed then, they are in that snapshot. This has easily been the greatest benefit of btrfs to me; I've deleted stuff by mistake, and screwed up other stuff, and brought them back in seconds using standard tools.

Rolling back to a snapshot is the option suited to system screw ups, where one doesn't know what has happened or what is wrong. Or one has really done one's best to break things...

[GreyGeek]

Good point, John!

I have, on occasion, found a need to pull a file out of a snapshot because of the fat finger syndrome. But for a total disaster, like yanking the power during a delete operation in which a file structure might be damaged or destroyed, reformatting the HD followed by rolling back is the best recipe.