[SOLVED] Error mounting an ext4 backup partition

[elbraca]

I recently encountered a problem that, after solving it, was repeated again and began to worry.

Consider a fresh Debian installation where I've an exclusive partition to / and another to / home. Later I decided to create with gparted an ext4 extra partition to use as backup of my most sensitive information, to which I didn't assign any function or flag. At first it worked without problems, until from one moment to the other didn't allow me to mount it anymore.

Analyzing the partitions I got

Code: Select all

# fdisk -l
/dev/sda1        2048     923647    921600   450M Windows Recovery
/dev/sda2      923648    1128447    204800   100M EFI System
/dev/sda3     1128448    1161215     32768    16M Reserved for Microsoft
/dev/sda4     1161216  628491121 627329906 299,1G Microsoft Basic Data
/dev/sda5   628492288  630194175   1701888   831M Windows Recovery Environment
/dev/sda6   630194176  747380735 117186560  55,9G Linux file system
/dev/sda7   747380736 1020817407 273436672 130,4G Linux file system
/dev/sda8  1020817408 1953523711 932706304 444,8G Linux file system

The /sda8 partition was created by gparted and isn't mounted at startup by itself, but I should mount it when I want it. When doing so, the system returns the following message:
Error mounting /dev/sda8 at /media/elbraca/Data: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/sda8" "/media/elbraca/Data"' exited with non-zero exit status 32: mount: mounting /dev/sda8 in /media/gbraca/Data failed: The structure needs cleaning

The first time I solved the issue by doing

Code: Select all

sudo fsck.ext4 /dev/sda8

letting me mount it without problems, although it showed as output that I had fixed some problems with i-nodes.

However, after restarting the issue appeared again and it doesn't seem to me to be any more casual. I've never had a problem with GNU Linux partitions, although I've never used an ext4 in this way since I always assign a mount point (/, / home, etc.) and I'm not sure if the root of the problem can come from there. By the way, I haven't used the same solution since I understand it has been a "patch" that didn't completely solve it.

I'm worried about losing the information on that partition, so I hope I can find some permanent solution for this. Has anyone else had this issue?

[pylkko]

So, you are making a backup of a disk to another area on the same disk?

Have you checked that the disk is ok (S.M.A.R.T?)

[elbraca]

So, you are making a backup of a disk to another area on the same disk?

Exactly. It is a primary partition apart from GNU Linux and Windows, in case any necessary reinstallation would be necessary.

Have you checked that the disk is ok (S.M.A.R.T?)

I did not review with S.M.A.R.T. because it's a new hard drive. Are there any considerations that I must have in order to verify it correctly with S.M.A.R.T.?

So far, what I did (on two occasions) was

Code: Select all

$ sudo fsck.ext4 -v /dev/sda8 

where it asks me if I want to repair some superblocks and problems with i-nodes.

After that, I call

Code: Select all

$ sudo mke2fs -n /dev/sda8 

to know what superblocks require repair, but it doesn't return anything at all.

I would still use

Code: Select all

$ sudo e2fsck -b block_number /dev/sda8 

to restore the super-block, but without the block numbers I can't do it. Consequently, the first command allows me to solve the problem and mount it only until I reboot the laptop.

[dasein]

So, you are making a backup of a disk to another area on the same disk?

Exactly.

Then it's not a backup. A backup is something that protects against catastrophic failure of the drive.

Have you checked that the disk is ok (S.M.A.R.T?)

I did not review with S.M.A.R.T. because it's a new hard drive.

Manufacturing processes are imperfect. New drives fail all the time (especially Seagate drives).

Actually backup the drive in question before you do anything else. "Anything" means fsck it, boot it, try to use it, etc.

[elbraca]

Then it's not a backup. A backup is something that protects against catastrophic failure of the drive.

Sorry, it was misinterpreted because I expressed it in general form (a bad habit in my country). The correct thing is that it will not let me mount a partition that I have destined to Data exclusively.

Manufacturing processes are imperfect. New drives fail all the time (especially Seagate drives).

Actually backup the drive in question before you do anything else. "Anything" means fsck it, boot it, try to use it, etc.

I've already been able to back up to another disk, so now I can run tests on this one.

I did an analysis with the tool of Disks that brings GNOME: "Data and test SMART". I used a short self-test and no errors were found. The disk is correct.

[dasein]

I used a short self-test and no errors were found. The disk is correct.

Short test only warns if a disk is about to fail. Run the long test.

Since you say that you have an actual backup now, you no longer have to worry about data loss. Clobber and recreate the partition in question. If you really want to err on the side of caution, zero-fill the drive using dd before recreating the partition. (man dd has details.)

[elbraca]

Well, the problem seems to have been solved after running the S.M.A.R.T. long test. It strikes me because no error was reported, says that the disk is correct and yet I had no more problems mounting it after running the long test. If I'm not wrong, SMART should have corrected it on its own previously, but this did not happen until I ran the test. The most important is that now is working fine.

Thanks for helping.