I made a major error while trying to extend the size of a xen image, I ended up truncating the image file, and I can't seem to find any ways of recovering the image.

I don't really care about much of the data, only a few perl scripts and the subversion data directory is important.

I've already remounted read only (which I assume was another error which could have let me recover using the journal, I should have frozen the fs instead), so at least nothing will be writing to the filesystem for now.

IIGC Photorec supports XFS, so it's worth a shot.

The only problem is its a 596GB perfectly healthy filesystem, and all I lost was a 4GB disk image. I can't see it working properly.

I wonder if remounting ro really blocks you from replaying the journal. Anyway. Why can't you run Photorec on your guest partitions directly? Now I don't run Xen but if there's a valid reason why you can't, could you at least dd it out to file or 'xm block-attach' to to some other domain?

remounting likely (though I'm not totally sure) sync's (or flushes) the disk. In order to remount the filesystem I had to shut down the VMs, and I was left with a truncated file. Had the FS been ext2 or ext3, It seems it would have been saveable, but XFS doesn't have any tools to scan the tree for old metadata and try to rebuild things.

So. What's the next step then. What's this Xen image? Partition or file? *Can* you reach it with Photorec?

Ah. I should have explained things a little better. Sorry. The "Xen Image" is a large 4GB file thats stores an OS install, that boots in Xen. It is a file, that lives on an XFS filesystem. And while I could run photorec on the device that the XFS filesystem lives on, theres over 500GB of valid data on there.

OK. With respect to the filesystem inside this Xen image, does Xen support dynamic allocation and preallocation like for instance VMware does? Was the total size of the Xen image before and after truncating the filesystem inside the image file the same? I'm asking because if Xen does it somewhat like Vmware or QEmu, then you can *enlarge* on-disk filesystem containers but you can't shrink them AFAIK, so if something gets truncated *inside* it'll be contained inside the image. If yes, then maybe this Xen image be loopmounted (losetup) or attached readonly to another domain. If no (meaning it uses resources in the host, which sounds weird to me somehow, or does allow for dynamic deallocation), then I'm out of ideas, sorry.

The image was truncated outside of the VM, that is, it was done on the host. I'm pretty sure that the data is gone at this point.

Unless the area the data resided wasn't written over there would be some minute chance, but given host system activity chances for recovery would be about zilch, yes.

At the time I posted, nothing besides the metadata for the file in question had been written to disk, so I could have successfully run something like photorec, but the filesystem is too large for it to be worth my time looking for the embeded files. 596GBs of data is a lot to go through.