rm'd a project that was months in the making a few days before launch... What to do if you kill the wrong file
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panic -
System shared this topic on
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicOnce upon a time I stumbled on a tool called “fsfreeze”. Might be useful.
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicUsually projects (especially large projects) are kept in a version control system like
git. This is a prime reason why. With version control, it wouldn't have mattered if you deleted the docker compose file, you could just bring it back. Also, usually every change has to go through version control, this way you always have a backup of the latest version of the file. -
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicWhy it wasn't in version control is the real issue here...
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicIf I deleted the wrong file I'd restore from backup. OneDrive, git, or the actual cloud backup.
I could throw my laptop in the ocean and lose nothing but time setting up my new one.
-
Why it wasn't in version control is the real issue here...
I'm not denying that stupid stuff didn't happen nor that this wasn't entirely preventable. There's some practical reasons that are unique to large, slow moving orgs that explain why it isn't (yet) in version control.
-
Usually projects (especially large projects) are kept in a version control system like
git. This is a prime reason why. With version control, it wouldn't have mattered if you deleted the docker compose file, you could just bring it back. Also, usually every change has to go through version control, this way you always have a backup of the latest version of the file.100%. The organization wasn't there yet and seeing that I wanted to remain employed at the time I wasn't going to put up a fight against management 3 layers above me. Legacy business are a different beast when it comes to dumb stuff like that.
-
Once upon a time I stumbled on a tool called “fsfreeze”. Might be useful.
As others pointed out, version control is probably the best fix for this in addition to traditional backups. My goal in this post was to help others that have yet to learn responsibility save their ass and maybe learn their lesson in a less pleasant way.
-
If I deleted the wrong file I'd restore from backup. OneDrive, git, or the actual cloud backup.
I could throw my laptop in the ocean and lose nothing but time setting up my new one.
The server we were working at the time wasn't configured with frequent backups, just a full backup once a month as a stop gap until the project got some proper funding. Any sort of remote version control is totally the preventative factor here, but my goal is to help others that have yet to learn that lesson.
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicPhotorec, on the other hand, was truly a gift from the cosmos
Can confirm. Over the years I've had recourse to this little tool several times and always found to to be almost disturbingly effective.
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panicIf I don't have the file elsewhere, I restore from backup.
-
100%. The organization wasn't there yet and seeing that I wanted to remain employed at the time I wasn't going to put up a fight against management 3 layers above me. Legacy business are a different beast when it comes to dumb stuff like that.
put up a fight against management 3 layers above me
Eh, yeah. I've been in that kind of situation before. Sucks.
Still, you should try to go rogue where you can. Not for the company, fuck the company, do it to protect yourself. Like, maybe you could create your own git repo and push the changes there yourself. Don't tell anyone else, just do it privately. You don't need to use GitHub, you could push to a local folder on your computer or a USB drive.
-
Photorec, on the other hand, was truly a gift from the cosmos
Can confirm. Over the years I've had recourse to this little tool several times and always found to to be almost disturbingly effective.
Disturbingly effective is definitely the right phrase. It's actually inspired me to create a script on my desktop that moves folders to ~/Trash, then I have another script that /dev/random's the files and then /dev/zeros them before deletion. It eliminated risk of an accidental rm, AND make sure that once something is gone, it is GONE.
-
Yep... it happened to me. I killed a docker compose file with 550 lines of God-forsaken yaml less than a week before the project launch, and the most recent backup we had was nearly a month old and would have taken at least a day to get back up to speed. With a stroke of luck, I handled it about as well as I could have for on the feet thinking and I'd like to share my experience and lessons learned for anyone else that may ever find themselves in these smelly shoes:
Disclaimer! I'm a young engineer still growing my expertise and experience. Some stuff in here may be bad advice or wrong, like my assertion that using dd to pull data off of an unmounted drive doesn't risk data loss; I'm pretty damn sure of that, but I wouldn't stake my life (or your data) on it. I'll happily update this post as improvements are suggested.
IF YOU RM'D THE WRONG THING:
1. Stop all writes to that partition as quickly as possible.
this step has some optional improvements at the bottom
Up to this point I'd been keeping a lazy backup of the file deleted on another partition. In order to preserve the disk as well as possible and prevent overwriting the blocks with the lost file, I cd to the backup dir and run a docker compose down. There were a few stragglers, but docker stop $containerName worked fine.
2. Unmount the partition
The goal is to ensure nothing writes to this disk at all. This, in tandem with the fact that most data recovery tools require an unmounted disk, is a critical step in preserving all hopes of recovering your data. Get that disk off of the accessible filesystem.
3. Save what you have
Once your partition is unmounted, you can use dd or a similar tool to create a backup somewhere else without risking corruption of the data. You should restore to a different disk/partition if at all possible, but I know sometimes things aren't possible and /boot can come in handy in an emergency. It would have been big enough to save me if I wasn't working on a dedicated app-data partition.
4. Your sword of choice
It's time to choose your data recovery tool. I tried both extundelete and testdisk/photorec, and extundelete got some stuff back but not what I was looking for, while also running into seg faults and other issues. Photorec, on the other hand, was truly a gift from the cosmos. It worked like a dream, it was quick and easy, and it saved my sanity and my project.
5. The search for gold
Use "grep -r './restore/directory' -e 'term in your file'" to look through everything you've deleted on the part since the beginning of time for the file you need.
It was a scary time for me, and hopefully this playbook can help some of you recover from a really stupid, preventable mistake.
potential improvements
In hindsight, two things could have gone better here:
1. Quicker: I could have shut them down immediately if I was less panicked and remembered this little trick: docker stop $(docker ps -q)
2. Exporter running config: I could have used 'docker inspect > /path/to/other/partition' to aid in the restoration process if I ended up needing to reconstruct it by hand. I decided it was worth it to risk it for the biscuit, though, and choosing to shut the stack down as quickly as possible was worth the potential sacrifice.If you fight to preserve a running config of some sorts, whether k8s docker or other, MAKE SURE YOU WRITE IT TO ANOTHER PARTITION. It's generally wise to give an application it's own data partition but hey, you don't have a usable backup so if you don't have a partition to spare consider using the /boot partition if you really want to save your running config.
If you're considering a donation to FOSS, join me in sending a few bucks over to CGSecurity.
remove, recurse, force
wrong path, there is no backup
desperate panic -
Disturbingly effective is definitely the right phrase. It's actually inspired me to create a script on my desktop that moves folders to ~/Trash, then I have another script that /dev/random's the files and then /dev/zeros them before deletion. It eliminated risk of an accidental rm, AND make sure that once something is gone, it is GONE.
Yep, I use
trash-put, andtrash-emptywith a 30-day timeout. But no bit-scrubbing needed because the partition is encrypted. -
100%. The organization wasn't there yet and seeing that I wanted to remain employed at the time I wasn't going to put up a fight against management 3 layers above me. Legacy business are a different beast when it comes to dumb stuff like that.
git init .git doesn't need Github, Gitlab, or even a server. It's designed to allow devs to cooperate via patches and PRs sent by email.
-
100%. The organization wasn't there yet and seeing that I wanted to remain employed at the time I wasn't going to put up a fight against management 3 layers above me. Legacy business are a different beast when it comes to dumb stuff like that.
You can just "git init ." on your PC somewhere and color relevant stuff into it occasionally and commit. Might not be automated, might not be used directly in production (or on the prototype), but it at least exists.
-
The server we were working at the time wasn't configured with frequent backups, just a full backup once a month as a stop gap until the project got some proper funding. Any sort of remote version control is totally the preventative factor here, but my goal is to help others that have yet to learn that lesson.
Didn't even need remote version control. All it required was essential files version controlled in the local folder.
-
git init .git doesn't need Github, Gitlab, or even a server. It's designed to allow devs to cooperate via patches and PRs sent by email.
I'm aware. Any local storage wouldn't do much about a poorly aimed rm, though.
-
Yep, I use
trash-put, andtrash-emptywith a 30-day timeout. But no bit-scrubbing needed because the partition is encrypted.That's the move.
