On Thu, 2020-07-16 at 11:35 +0100, 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?

Yes. Find the process ID of the Qemu job and look in
/proc/${QEMUPID}/fd for the file handle showing it is connected to the
deleted image. Use cat to dump that handle to a file somewhere safe.

It will be an image of a running machine so you will need to run chkdsk
on it, but it should be similar to a power glitch and easily repaired,
especially if you quiet down activity in the VM before you take the
copy.

Once you have that you can try advanced things like pausing the VM and
see if qemu holds the file open. There are probably tools that will
create a file pointing to a given inode so you might be able to just
regenerate it.

> 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.
>