Howto recover from accidental mkfs
m (→Issues: Renamed to faq. Added Memory targets.)
m (Killian De Volder moved page Recovering from accidental mkfs to Howto recover from accidental mkfs: Following naming policy from https://ext4.wiki.kernel.org/index.php/Help:Editing)
Revision as of 07:04, 17 June 2014
This document is a draft regarding advise and actions you can take after running mkfs.ext on an excisting partition. But the document might also help in general recovery.
Please also note that this document has not yet been reviewed by others.
The first step is ofcours stopping the mkfs/mke2fs action as soon as possible. Do not take any rash decisions.
If the partition is still mounted
If you managed to format drive while it was mounted (possible in some senarios) you might want to perform the following actions:
$ mount /path -o remount,rothis should prevent any extra problems to be created
- It could however be argued that not doing this might cause ext to rewrite certain data. But standard practise is never to write to broken FS.
$ echo 0 > /proc/sys/vm/vfs_cache_pressure. This will ensure any information still held by the kernel to be kept.
- Be carefull as this setting will never free vfs_cache data, and could OOM your system.
- Run dumpe2fs on the block device.
- You might with to use
$ dumpe2fs /dev/XXXto compress the file as it can be large.
- The manual of dumpe2fs states
Note: When used with a mounted filesystem, the printed information may be old or inconsistent.
- However since we want to old state this is a good thing.
- You might with to use
- Note any information you that might not be included dumpe2fs. Things that come to mind are:
- Number of inodes.
- Journal size.
- Filesystem features (should be included in dumpe2fs)
- UUID from
/dev/disk/by-uuid/(this should contain the old UUID in case it was overwritten by mkfs) (This can potentially be used for checksums later.)
Now the good news, in some senarios a large portion is still accessable.
First try obtain the files you want back first.
You can use
$ cat /mountpoint/dir/file (full path is required, as directories might be gone, caches might however allow you to access the data.).
You can also try to obtain the file from
If you have all the single files you need, you can continue with recovering entire directories.
In most cases you will notise
$ ls /mountpoint is empty.
However in some cases you can still
$ cd /mountpoint/sub/dir/.
From here you might still be able to initiate a copy data.
Some isues you might face when repairing your filesystem:
memory allocation failed
If you receive this error you do not have enough memory to repair this filesystem. Because of the damage e2fschk might need more bitmaps then usual to check this filesystem.
To resolve this error first try to see if you can add more memory to the system. If this is not an option, consider using zram, zcache or other memory compression techniques. Finally you might wish to add extra swap space.
Please however note that some part of e2fschk use rb_trees. These trees touch many small part of your memory (or swap page). As a result many pages will be paged in, resulting in verry poor performance.
Another possibility is to use scratch_files. To enable this edit
Howmuch memory will I need ?
The amount of memory you need can be large. This are some of the numbers seen during checks.
|Disk Size||Block Size||e2fsprogs version||Required memory|
You might wish to consult the Mailinglists archives for advise and simular issues.