Data Recovery on Linux

1

1

I recently purchased a new computer so that I could upgrade my old Linux machine. My old machine was running Ubuntu 16.04 Server LTS. The operating system was installed on a 256 GB SSD, while a single 7 TB HDD was used for data storage. Like the SSD disk, the data drive was connected to the system via SATA. In other words, the data drive is not an external USB drive.

On the new system I have installed Ubuntu 18.04 Server LTS on a new 1TB SSD drive. Then, I physically moved the 7 TB HDD from my old machine and connected it to the new system. However, to much surprise previously stored data on the old 7 TB HDD is now missing, that is, Ubuntu 18.04 is reporting that the disk does not contain any information, meaning it does not show any files or directories. Ubuntu displays 7 TB of free space.

Of course, I have not repartitioned the drive or written any data to the it. All I have done is to physically connect the old drive to the new machine and boot Ubuntu 18.04 LTS. The file system used is ext4.

What is going on and how can I recovery my data?

I have tried tools like testdisk, photorec etc., but with no luck.

Here is some output:

sudo fdisk -l

Disk /dev/loop0: 86.9 MiB, 91099136 bytes, 177928 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 89.5 MiB, 93818880 bytes, 183240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 89.5 MiB, 93835264 bytes, 183272 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: XXX

Device           Start         End     Sectors   Size Type
/dev/sda1         2048 15628052479 15628050432   7.3T Linux filesystem
/dev/sda2  15628052480 15628053134         655 327.5K Linux filesystem

Disk /dev/sdc: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: XXX

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048       4095       2048    1M BIOS boot
/dev/sdc2   4096 4000794623 4000790528  1.9T Linux filesystem

Here is what Foremost reports:

Invocation: foremost -i /dev/sda1 -t png -o /home/erran/foremost
File: /dev/sda1
Start: Thu Jan 10 13:55:00 2019
Length: 7 TB (8001561821184 bytes)

Num      Name (bs=512)         Size      File Offset     Comment

Finish: Fri Jan 11 02:27:21 2019

0 FILES EXTRACTED

More output based on suggestion from @agc:

sudo dd if=/dev/sda count=1 bs=1G | gzip -1 | wc -c
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.43023 s, 127 MB/s
7332366

sudo dd if=/dev/zero count=1 bs=1G | gzip -1 | wc -c
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.16624 s, 258 MB/s
4683762

Erran Morad

Posted 2019-01-10T11:22:58.097

Reputation: 11

2Can you move the 7 TB HDD back to the old machine to see if the data reappears? – Andrew Morton – 2019-01-10T11:42:55.280

I guess I could do that, but since there is some effort involved in this process I would like to solve this without going through the hassle of taking out the drive, reconnecting it to the old machine etc. – Erran Morad – 2019-01-10T11:57:32.823

1Did the old machine have one volume spanning both physical disks perhaps? – Andrew Morton – 2019-01-10T12:02:36.573

Have you tried Foremost? – kenorb – 2019-01-10T12:11:02.277

See: How do I recover lost/inaccessible data from my storage device?

– kenorb – 2019-01-10T12:11:23.110

1Can you post some command outputs what you've tried with testdisk? – kenorb – 2019-01-10T12:13:49.523

Just a SATA cable going from the HDD directly to the motherboard. No USB-bridge involved now. No RAID-kontroller. I have not enabled any encryption, unless this is default in Ubuntu 18.04 LTS Server. – Erran Morad – 2019-01-10T12:35:18.140

I have not tried foremost, but will give it a shot now. – Erran Morad – 2019-01-10T12:36:04.973

I only pasted the information about the data disk. If it helps I can paste the output of the OS disk as well. Foremost is running now and I will update the post with the output of that when it is done. – Erran Morad – 2019-01-10T12:53:30.457

2What does "the disk does not contain any information and that the disk has 7.3 TB of free space" mean? The fdisk output says it contains at least the partition table. What happens when you mount -o ro /dev/sda1 /mnt/whatever? If it mounts and the data is not there at all, then maybe it is elsewhere, like on the old SSD. How much data is supposed to be there? Is the following scenario plausible? The HDD was (by mistake) never mounted in the old OS and all the data ended up in /alleged/mountpoint/but/not/really on the old SSD. – Kamil Maciorowski – 2019-01-10T12:59:06.980

At this point, it is too late to say to not do anything to the 7 TB HDD. I suggest that it is worth the effort to put it back in the old computer - if the data reappears then we can check what adjustments need to be made for the disk to work in the new computer. – Andrew Morton – 2019-01-11T10:01:18.917

@KamilMaciorowski Updated my original post to answer your questions. How can 7 TB (the 7TB disk was full) of data be stored on a 256GB SSD or "elsewhere"? – Erran Morad – 2019-01-14T08:57:10.463

How can 7 TB (the 7TB disk was full) of data be stored on a 256GB SSD or "elsewhere"? -- You didn't tell us how much data was there. You didn't say there was no other storage (that might by "elsewhere"). Considering the information you provided my scenario was at least plausible. – Kamil Maciorowski – 2019-01-14T09:02:59.410

Answers

0

Don't panic... it takes a long time to erase a 7 TB hard disk.

Take a minute to check if the data's really gone, by compressing the first Gigabyte of the whole disk with gzip -1, and comparing the size. For example, using my current working hard drive:

dd if=/dev/sda count=1 bs=1G | gzip -1 | wc -c

Output, after a minute:

1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 54.3403 s, 19.8 MB/s
1072079878

The last number 1072079878 is the compressed size, which is quite close to the uncompressed size. Partly this is because gzip -1 goes fast and doesn't compress very well, and partly it's because the first gigabyte of /dev/sda has plenty of data in it.

Compare that to the same code, but using /dev/zero, (an endless stream of zeros):

dd if=/dev/zero count=1 bs=1G | gzip -1 | wc -c

Output, (runs in under 10 seconds):

1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.65898 s, 124 MB/s
4683762

Since the data is all zeros, even gzip -1 can compress 1G down to 4M, (less than 1% of the original size).

Assuming there's no malware involved, then only if your hard drive shows a compression ratio that resembles compressing /dev/zero, (and only if it did so on both computers), would there be something to worry about. Otherwise, it's probably some BIOS config inconsistency...

agc

Posted 2019-01-10T11:22:58.097

Reputation: 587

1To check the whole disk, (which hopefully wouldn't be necessary), remove the count=1 option from dd. Yalla! – agc – 2019-01-12T05:33:05.893

Asked: 2019-01-10T11:22:58.097

Viewed: 125 times

Active: 2019-01-14T08:55:39.143