After running xfs_repair -n, I get some stuff that looks like this: entry "backup" in directory inode 128 points to free inode 12583040, would junk entry entry "desktop" in directory inode 128 points
OK, but on you bullet proof vest and thermally insulated gloves.... Try this for starters: mount -o ro,norecovery It will skip processing the log. You can try copying files out of the filesystem, hop
I will try that, but I'd like to note one thing. The drive actually had everything deleted with [essentially] 'rm -rf /mnt/drive/*'. It's not corrupt (just deleted), and I think mounting it might sho
Adam Milazzo wrote: I will try that, but I'd like to note one thing. The drive actually had everything deleted with [essentially] 'rm -rf /mnt/drive/*'. Isn't there still a utility to print out the c
I'm not sure, but what you described sounds useful. I might try to do some research regarding that as well. Using 'xfs_repair -n' printed out some helpful-looking information, and I've had some succe
A few months back I repartitioned a BSD box before I realized that I lost my backups. The tool that helped me recover most of my data was Python. Why Python? - Interactive scripting language With an
<snip> It would be interesting to know if there is anything that could (at least in principle) be done in this situation. A while back, we had all the scratch files deleted on a job that had been run
Getting stuff back in XFS is always problematical, it is so good at cleaning up after itself. With some filesystems, once you get to an inode, getting the data back is not too hard. With XFS, when yo
So, I did try one more thing: xfs_db -x /dev/xxx this enables a write command Using the commands inode 132 write core.nextents 1 p I was able to get my extent info back again. So presuming you can fi
After running xfs_repair -n, I get some stuff that looks like this: entry "backup" in directory inode 128 points to free inode 12583040, would junk entry entry "desktop" in directory inode 128 points
OK, but on you bullet proof vest and thermally insulated gloves.... Try this for starters: mount -o ro,norecovery It will skip processing the log. You can try copying files out of the filesystem, hop
I will try that, but I'd like to note one thing. The drive actually had everything deleted with [essentially] 'rm -rf /mnt/drive/*'. It's not corrupt (just deleted), and I think mounting it might sho
Adam Milazzo wrote: I will try that, but I'd like to note one thing. The drive actually had everything deleted with [essentially] 'rm -rf /mnt/drive/*'. Isn't there still a utility to print out the c
I'm not sure, but what you described sounds useful. I might try to do some research regarding that as well. Using 'xfs_repair -n' printed out some helpful-looking information, and I've had some succe
A few months back I repartitioned a BSD box before I realized that I lost my backups. The tool that helped me recover most of my data was Python. Why Python? - Interactive scripting language With an
<snip> It would be interesting to know if there is anything that could (at least in principle) be done in this situation. A while back, we had all the scratch files deleted on a job that had been run
Getting stuff back in XFS is always problematical, it is so good at cleaning up after itself. With some filesystems, once you get to an inode, getting the data back is not too hard. With XFS, when yo
So, I did try one more thing: xfs_db -x /dev/xxx this enables a write command Using the commands inode 132 write core.nextents 1 p I was able to get my extent info back again. So presuming you can fi