New answers tagged

0

Getting the message "buffer I/O error" typically indicates a hardware issue with your disk, but it could just be that the filesystem is asking the system to do things that don't make sense as a result of its corrupted state. Your best bet is to run fsck on the affected filesystem, and then look in /lost+found for recovered inodes.


1

By far, my favorite vim plugin for handling this is Recover.vim. When you edit a file which has an associated .swp, it gives you the option of showing the diff between the two. This is invaluable. For example: $ vi foo.py ... Please choose: D[i]ff, (O)pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort, (D)elete:


0

There are quite a few functions to help with this, see the relevant page on the Vim wiki. The article is very long, so I won't copy it all here, but the basic premise is to save to another file and then diff the two.


1

An alternative may be using del instead of rm for deleting: http://fex.belwue.de/fstools/del.html del has an undelete function and works with any file system. Of course it is not a solution if you have already deleted your files with "take no prisoners" rm :-}


2

In this situation you should use the tar --numeric-owner option. The files in the archive were created using the user IDs from the /etc/passwd file that's in the archive. It's possible that users and groups exist in the archive with different numeric IDs than on the Live DVD image. Even if you ran the same Live DVD each time, there can still be different ...


0

since you have the 600gb empty you can mount your current HD and copy its files to the 600gb ! or you can make a new backup using dd+gzip and you will have chance to restore your hard drive without problems of loosing space. if you want to do that from your current runing os : mount your current hd (since it is an ext4 it can be mounted on ...


1

Debugfs is not a file recovery program. That it can sometimes recover deleted files if you are very lucky is an accident. File recovery in real operating systems (as opposed to MS-DOS, for example) is spelled "backups".


0

1) Yow to use photorec step by step http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step 2)You can select format using Space avaible format http://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec 3) You can add your own format http://www.cgsecurity.org/wiki/Add_your_own_extension_to_PhotoRec 4)To access your files from a normal user ...


1

Could be late, but was digging in the same problem and found the topic. Hope this will be usefull for someone too. Working excellent in Ubuntu 14.04: sudo -i mdadm --assemble --scan You will get: mdadm: /dev/md/1 has been started with 1 drive (out of 2) Then mount and see your files: cd /mnt && mkdir to-restore-md1 && mount /dev/md1 ...


0

Make sure that you data is still being copied - check the output files, and make sure that their size keeps increasing. Failing hard drives have a tendency to freeze up when you try to copy a lot of data off them at once. If it looks like it isn't doing anything, it's probably best to stop the operation, then go back and copy one directory at a time, so ...


2

Your information is contradictory. /dev/md0 cannot simultaneously be a PV and have a partition table. file would recognize a PV. It seems that md0 is partitioned so that the LVM volume is rather /dev/md0p1 or /dev/md0p2. Maybe for some reason pvscan / vgscan ignore /dev/md0 / /dev/md0p1 (and thus LVM cannot find the UUID). You may run pvscan through strace ...



Top 50 recent answers are included