First, understand the difference between partitions and filesystems. In this answer, I will use these terms very precisely, so I want to be sure you understand the distinction:
- A partition describes a set of sectors on your hard disk. That is, a partition can be sectors 2048 to 1126439 or sectors 4198440 to 15628053134. Partitions are defined in partition tables, which are simple data structures that contain those sector numbers and a few other pieces of partition metadata, such as type codes and possibly names. Two common partition table types are the Master Boot Record (MBR) and the GUID Partition Table (GPT). The former was the dominant partition table type until about four or five years ago; but with the introduction of Windows 8 and the rapid shift from BIOS-based to EFI-based computers, GPT has risen dramatically in popularity. Which partition table you used is critical one for your question, as described shortly.
- A filesystem is a much more complex data structure that typically resides within a partition (or sometimes another container, such as a logical volume in an LVM setup, or even a file, as in a downloaded
.iso
image file). Filesystems enable the computer to locate, read, write, and otherwise manipulate individual files. Common filesystems on Ubuntu include ext2/3/4fs, Btrfs, XFS, and JFS. Some others, like FAT, are often used for cross-platform purposes. NTFS is the native filesystem for Windows, and HFS+ for macOS (although Apple is transitioning to APFS). If your computer boots in EFI mode, chances are the first partition held a FAT filesystem; but that filesystem would also have been small and would therefore be completely overwritten and will not be recoverable. (Fortunately, re-creating this EFI System Partition, as it's called, is possible.)
The terms partition and filesystem are sometimes used interchangeably, but the distinction is important for your case. Ultimately, you're most interested in the filesystem data, but to access a filesystem, its starting point must be known, and that start point is normally provided by the partition data.
Given your current situation, there are several possible ways to recover your partition table and/or locate the start point(s) of at least some partitions:
- Use GPT backup data -- Both GPT and MBR store the partition table data at the start of the disk, which your accident has erased; but GPT also stores a backup of this data at the end of the disk. Thus, you should be able to use the GPT backup to recover the entire partition table. (Note that this will not recover the rest of the data you've overwritten; it's likely that at least one filesystem will be damaged.) AFAIK, the best Linux tool for this type of recovery is my own
gdisk
, which comes standard with Ubuntu. See this page for details. In brief, you'll launch gdisk
on the disk and, if it asks you, tell it to use GPT. gdisk
might recover everything at that point, but you may need to type r
to enter the recovery & transformation menu and then use b
and/or c
to read the backup metadata and partition table, respectively. You can use p
to view the partition table as gdisk
currently sees it. When you're convinced it's recovered, type w
to save the changes. Be careful, though! Once you type w
, gdisk
will overwrite both the main and backup GPT data, so if you do this before you recover the correct partitions, you won't get a second chance at recovery! If you're uncertain, quit out of the program without saving changes by typing q
. You can then do more research and try again.
- Use Linux's in-memory partition data -- So long as you do not reboot or use certain commands related to partitions, the Linux kernel maintains a list of partitions, including their start points and sizes. You can read this information from the
/sys/block/{disk}/{part}/
directory in its start
and size
files. For instance, /sys/block/sda/sda1/start
has the start point of /dev/sda1
and /sys/block/sda/sda1/size
has the size of /dev/sda1
. You can use this information to re-create a partition table. You'd extract the information on all your partitions (say, cat /sys/block/sda/sda*/start
and cat /sys/block/sda/sda*/size
to get the start points and sizes of all partitions on /dev/sda
), then use fdisk
, gdisk
, or parted
to re-create partitions that match what the kernel has recorded. (Caution: Some partitioning tools, such as GParted, create new filesystems when new partitions are created. It's imperative that you not do this; you want to create new partitions without modifying a single byte of the contents of the partitions you create.) Note that you'll still need to fill out metadata that the kernel does not record, such as partition type codes. Also note that the kernel records the start point and size (length) of each partition, but many partitioning tools ask for the start point and end point, the latter being the start point plus size minus 1. Be sure to understand what your partitioning tool wants and feed it the correct values.
- Use TestDisk -- If your computer uses MBR and you've rebooted, or if the preceding approaches fail, you can use TestDisk to recover partitions that match your filesystems. TestDisk works by scanning the entire disk for filesystem data structures. It can then modify your partition table, or create a new partition table, with partitions that match the filesystems it finds. Note that TestDisk is likely to fail for your first partition or two; however, this approach may work for recovering partitions that begin beyond the end of the area you've accidentally overwritten.
- Do it blindly -- The first partition on the disk usually begins at a fairly predictable location. In particular, sector 2048 is a common starting point for disks partitioned recently (in the last four or five years). Older disks usually had a first partition that began on sector 63. Some disks, particularly those partitioned in macOS with GPT, have a first partition that begins on sector 40. Thus, if you know enough, you might be able to correctly guess where the first partition began. Given that you've wiped the first 4GB of your disk, though, this knowledge may be worthless; many disks have small (1MiB to 1GiB) first partitions, so you may well have completely overwritten the entire first partition, and well into the second one. If you know that the first partition was a specific size that was much bigger than this, though, or if it filled the entire disk, knowing the start point may enable filesystem-level recovery tools to restore some of the filesystem's data; or you may then be able to recover an intact second partition. This approach is obviously one that's very risky, but if you're desperate enough, you might get lucky with it.
Overall, your best bet is if you used GPT; in that case, your backup GPT data should be intact and you should be able to recover the entire partition table. Even in this case, though, the filesystem data may be partially or completely wiped, at least for the first partition or two. Recovering any data in the first 4GB (the area you accidentally wiped) will be impossible. If a partition begins within that wiped area but extends significantly beyond it, you might be able to use fsck
(or similar tools in other OSes) to recover the filesystem, or at least most of it. There are advanced fsck
options that might help you with this task, but I'm not an expert on their use. Note also that fsck
is really a front-end to filesystem-specific tools such as e2fsck
, and filesystem-specific options for these tools may be important in recovering your filesystem(s).
If you haven't rebooted, you might try backing up whatever filesystem(s) are most at risk, using ordinary file-level commands such as tar
or cp
. There is a risk that Linux will attempt to read filesystem data from the overwritten section of the disk, become confused, and completely hang the computer. In a worst-case scenario, the confusion might even cause writes of corrupted data beyond the damaged area, thus making matters worse. Thus, this approach is not without its risks. Even so, it might be worth taking the risk to back up important user data to an external drive.
Another data-recovery approach is to use PhotoRec. This tool searches the disk, much like TestDisk, but PhotoRec searches for common file types. Thus, it can be used to recover files even if the filesystem data structures are badly damaged. This tool might be useful if a partition began in the damaged first 4GB of your disk but extends beyond that area. If fsck
can't recover the filesystem well enough to be mounted, PhotoRec might at least recover some files from it. Be aware, though, that PhotoRec does a poor job of recovering filenames and directory structures. You'll be left with a mound of poorly-named files you'll have to search manually to figure out what you've got.
If you booted in EFI mode, your ESP is almost certainly gone. If you can recover the partition table, you can create a fresh FAT filesystem on the ESP and then use Boot Repair to return Ubuntu to bootability. Conceptually similar repair procedures are possible for Windows, but I'm not familiar with them. If you dual-booted with Windows, you should ask about this on a Windows forum. I recommend restoring the Windows boot loader first and then using Boot Repair in Ubuntu. If you do it the other way around, the computer will end up booting straight to Windows. This issue can be fixed, but it's better not to have it at all.
If you booted in BIOS mode, your boot loader is also destroyed. Boot Repair can recover GRUB once your Ubuntu partition(s) are restored. Depending on the location of Windows (if you dual-booted it), you may need to recover its boot loader using Windows techniques and tools.