Tag Info

New answers tagged

0

I might try extracting the data files after booting back to windows using windows tar. If tar omitted some files while you were creating the archive, it probably would have given some error messages. Also, you can list the contents of a tar file with: tar tvf tarfile.tar.gz


1

The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive. As for going directly between sdc1 to sdd1, I've always been reluctant when it comes to copying directly from and to a partition, as opposed ...


1

First, are you sure you destroyed your data? mkfs.vfat wouldn't run on a whole disk unless you specified -I flag. fdisk -l /dev/sdb outputs no partition? If so, you may have a luck with testdisk. It's a very useful tool to retrieve your deleted partitions. Just run testdisk /dev/sdb and choose "Analyze". Most of the time, it is able to find your deleted ...


3

If you are running an ext3-4 filesystem, you can use extundelete. As you probably do not have it installed, you should boot from a Linux CD and use that to download/install (in RAM) and do the recovery. Installing on your system, or any other activity on your system, might reuse the disc blocks that were freed by deleting the script. So it is best to keep ...


0

I had overwritten a text file (VQ1.txt) with 12 hr worth test data:( A notion that unix saves previous version of the file in text.txt~ format, made me look into folder containing the overwritten file with $ -ll Full list showed VQ1.txt~ that had my 'lost' data! $ cat VQ1.txt~ Start time at: Thu Apr 2 18:07:23 PDT 2015 User, KW: 12hrFA_OEM_HelloVoiceQ ...


0

Typical usage scenario when undeleting all files includes need to restore all files deleted from /dev/sdX1 during approximately last hour: mount -o remount,ro /dev/sdX1 extundelete --restore-all --after $(($(date +%s) - 7200)) /dev/sdX1 find RECOVERED_FILES/ If satisfied with recovered files: mount -o remount,rw /dev/sdX1


4

AFAICT, no. The problem is that the gzip process will create a new file and will free the previous (the unzipped) one, including a removal from the directory. If no other hard-link in the filesystem is pointing to the file it will get lost once the last file descriptor refering to it is closed. For the future you'd be advised to synchronize the access to ...



Top 50 recent answers are included