From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
before you change anything it would be good to use dd and save the whole drive to a bigger drive or maybe compress it with gzip while using dd to save it to a slightly smaller one. That takes a very long time, but gives you the ability to start over with your recovery. Only do that if it's worth to wait several hours.
photorec can also recover some files by looking at the raw data still there, if all else fails.
That’s what people always underestimate about data recovery jobs: you need lots of space. One copy for safekeeping. One to work on. One disk of the same size you store recovered files on.
Whenever friends or family ask me to look at a disk I always tell them to give me the disk and two new ones of the same or greater capacity and I’ll give it a shot. Usually they discover the data isn’t that important after all. If it is I have all I need.
use dd and save the whole drive to a bigger drive or maybe compress it with gzip while using dd to save it to a slightly smaller one
command would be something like this:
dd if=/dev/..../myparition|gzip status=progress > /mnt/external_hd/mypartition.gzip
Wouldn't you want to use
dd if=/dev/sda3 of=/dev/sdc1 status=progress && sync
Where /dev/sda3 is the damaged partition and /dev/sdc1 is the freshly formatted external drive
You'll find your attached devices with lsblk
You're going to want to make sure /dev/sda3(broken partition) is unmounted so as not to write any more data to it.
To add on to this answer (which is correct):
Your "of" can also just be a regular file if that's easier to work with vs needing to create a new partition for the copy.
I'll also say you might want to use the block size parameter "bs=" on "dd" to speed things up, especially if you are using fast storage. Using "dd" with "bs=1G" will speed things up tremendously if you have at least >1GB of RAM.
I totally spaced on BS=4M which I believe is the standard block size for ext4
this clones one parition to another which is fine if you have free partition with enough space lying around. My code was for taking compressed backup of the partition to be restored later if needed. Its less convenient but doesnt require as much space nor does it require an entire partition
Don't you have to read the partition to compress it, which is fine on a healthy partition but can further damage a broken one?
depends on what you mean by "broken". If broken means has bad sector or other hardware issue, then yes OP should transfer data to healthy partition and work from there. though it certainly won't hurt if he attempted to recover data from broken partition (worst the HD dies and OP restore the backup on healthy HD) However he said "i broke my partition" which make me think its software issue, not hardware. in which case, would be faster to recover data directly after taking backup
First thing is to not mount it at all. Any writes to the overwritten partition will corrupt your data.
Second thing: install system rescue cd to a live usb and boot it. Look into testdisk and photorec. It's been a while since I've had to use these tools, but I believe testdisk can restore the partition and photorec can find files in a file system that has been deleted. I would try running photorec first to save the recovered files to an external hard disk, and then testdisk to try restoring them. But disclaimer: it's been a while since I've had to do this, so my memory is foggy here.
Good luck!
Try testdisk. It can find a filesystem, copy files from it or restore the partition that contained it.
It would help if you told us what exactly you did to break the partition.
You can try fdisk.
If the partition table is there - create a new partition at the exact same location, of the exact same size.
If the partition table is not there - create *the exact same type (mbr vs gpt) partition table, then do the first if.
Fdisk should tell you that it found a filesystem signature. Do not wipe it.
there - create a new partition at the exact same location, of the exact same size.
... exact same starting block, size and geometry.
Check out testdisk file recovery.
Seconded. This is one of the things testdisk is built for, searching for lost filesystems and adding partition table entries to recover them.
Depends on how you "broke" it.
First step is to back up whatever data is there. Boot into a rescue distro like GRML dd the block device to an external hard drive.
If you nuked the partition table, there may be additional work to rebuild it if you used GPT rather than MBR. But gdisk should also tell you if there are backups, which would make your life way easier.
If you still have a partition (like /dev/sda1) but the mount command claims that it cannot find a valid ext signature, you might be able to simply use mkfs.ext4. It's counterintuitive, but this isn't destructive and will recreate the filesystem leaving the data alone. And if it does turn out to be destructive, that's why you have your backup.
To recover from the backup, you can use scalpel or photorec from the testdisk package. Photorec holds your hand and can be run in read-only mode. Caveat: These tools work by looking for specific file headers and makes a best guess as to where it'll end (if the format doesn't have a defined footer).
In the car now, but I can respond with more detailed steps if your other options don't pan out.
Two tools worth using:
DMDE
Photorec
If the data is extremely important make a back up first.
Did you delete the partition? Or quick format?
Now learn 3:2:1 backup principles, this problem will recede, the lessons learned are for a lifetime, or more....