[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 17/07/2020 00:04, fraser kendall wrote:
On Thu, 16 Jul 2020 11:37:03 +0100 fraser kendall <lfs.mailing@xxxxxxxxxxxx> wrote: Many, many thanks to everyone for their invaluable posts. The image has been restored and is now running on two identical machines. I'll post below for the record, but wanted to put my thanks at the top of the list. The file was retrieved and restored on the critical machine without any loss of service or uptime; the rescue process was seamless. So, thanks to everyone for these most excellent advices. Again and again.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.[cut]Best option: 1) can I retrieve the deleted qcow image from a running instance of that image?Yes. 1) open root terminals: a,b,c,d a) # find /proc | grep w7 note pid of deleted file and keep terminal open for reference and b) # tail -c +0 -f /proc/[pid]/fd/xxx > /srv/qemu-w7-tailed (keeps second instance of file in /proc) and c) # rsync -a /proc/[pid]/fd/xxx /srv/qemu-w7-rsync and/or d) # cp /proc/[pid]/fd/xxx /srv/qemu-w7-cp 2) copy the 'tailed; image to an appropriate second machine copy the original qemu-system commands for the deleted image and issue them for the 'tailed' image on the second machine confirm that the 'tailed' image is a working clone of the original when *completely* satisfied it is working as expected 3) close the original instance on the first machine (Point of no return!) issue the same qemu-system commands for the 'tailed' image on the first machine and confirm it is a working clone of the original When fully satisfied all is in order, the clone on the second machine can be closed and archived as a backup the rsync and cp versions are redundantFall back option: 2) does anyone know if a new installation of the (Dell) W7 iso will still activate now that W7 is EOL?No. It won't even install. The installation arrests after windows files are unpacked: qemu enters a terminal 'pause'.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)?No. the cloned image is 23G.
That's such a neat bit of lateral thinking - I'm making a note of this trick to whip out if I ever need it in the future. Never been in the position of having to recover a file that has been queued for deletion from disk _but still has open handles from running processes on it_ so is still available. Grabbing it from the file descriptor is smart, I like that so much :]
Normally I'm recovering files that have been accidentally trashed from disk the normal way with no chance of that being an option but next time someone kills off a VM backing file while the instance is still running, I'll know what to do.
Of course I have backups and presumably after that narrow escape, you do too now!
Q: how are you doing your Win7 install? I've built Win7 VMs recently without any installation issues but if you're trying to use an OEM image all bets are off I guess. You can certainly build and deploy with WIM still and activation is obviously something you have to take into your own hands now.
-- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq