[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 16/07/2020 11:37, fraser kendall wrote:
I have just done the stupidest thing. I was freeing up (rm -rf) space on what I thought was a storage directory (/srv), but I have now just discovered that it contained a critical qemu image. The image is a W7 VM and is still running; it appears unaffected. The /srv partition is the largest on this machine and the testdisk recovery image of this partition (~170G) is too large to fit anywhere on the hard drive. This machine is mission critical. I cannot take it offline for another 6 hours, and I'll need to have it back up asap, (within an hour) so I need to plan my attack. So some very naive questions. Best option: 1) can I retrieve the deleted qcow image from a running instance of that image? Fall back option: 2) does anyone know if a new installation of the (Dell) W7 iso will still activate now that W7 is EOL? I know that option 2 (writing to disk) will reduce the possibility of a testdisk recovery. So, here's Q3: can i squeeze the second W7 VM into a 6G qcow image (remaining free space in /home)? I'm not going to do anything for a while, except think. And hide from the boss. All help would be appreciated.
Haha, whoops... We've all done it though ¯\_(ツ)_/¯1: I'm pretty sure no, any attempt to clone the running 'orphaned' VM will try to reference the on-disk files for a copy, which of course won't work. You really want to avoid writing to the disk any more as well of course.
2: Good question but I presume not now it's fully EOL. If you're having to activate new Win7 VMs to rebuild it or something you can buy yourself time with 'slmgr -rearm' or similar just to get by. There are plenty of tools available online for sysadmins with little patience for Microsoft's activation nonsense when they're rushing to fix critical problems - which I'm sure you know about.
3: It sounds like the machine in question is really up against the wall and that's seriously hampering your recovery options. Is is that short on space (well you did say you were freeing up room when this happened I guess)? You've also got a very narrow window to work within it seems.
Can you say a bit more about the machine? It's presumably a linux box, and is the /srv partition that was holding the qemu image formatted ext4? Any RAID or anything to complicate things?
I'd say you have a choice to make - one little hour isn't enough time to reliably recover that file so you need to decide what's more important, that qemu image or the machine's uptime. If it's uptime then you're screwed and start planning for rebuilding the image from scratch. If it's the image, then you should have already sacrificed uptime and turned the damn machine off to stop it writing to the disk!
You _may_ have a middle option if you're lucky - have a spare disk on hand and use the single hour you have to clone the disk from the qemu box to the spare disk and then swap it in. Test and reboot your system so it's back up and running for the end of your window but now you've got the original disk with your deleted qemu file in it and as much time as you need for recovery.
Speaking of which, presuming it's ext4 you might want to try out ext4magic for undeletion - other than that it sounds like you already know testdisk and can do the recovery bit yourself. But as you know, it's really not helping you that the system is still up and running and scribbling all over it's storage as we speak.
Good luck! * PS: I made it this far ok but now I have to ask: WHY IS IT NOT BACKED UP ARE YOU INSANE -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq