Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a problem with my home server setup. The problem is that sometimes, but really rarely, it reverts (for a lack of a better term) all my data back to an earlier state (somewhere between months and weeks earlier).

The setup is a 4TB ext4 on a Software RAID 5 with 3 disks running on an Ubuntu 12.04 (linux 3.2). Samba serves files of that partition.

/proc/mdstat tells me that the array is healthy smartclt -H /dev/sdX says PASSED for all devices. I tried to find something in the logs but I couldn't find anything suspicious.

Last time the error occurred I rebooted the server whilst using files on the shear however fsck didn't find any errors.

The nature of the error baffles me. Since ext is not a copy on write file system, I would have assumed something like this is impossible. If you can think of any diagnostics I can run, please don't hesitate.

I guess the question is what happened to my data and how can I stop it from happening again?

-- edit --

OK I found the error: The problem had nothing to do with ext4. The problem was the way I mounted the device.

I have the raid 5 for my data and a raid 0 with an backup. But the way I mounted this at startup was not 100% stable; sometimes the backup was mounted as the main.

From /etc/fstab:

# main RAID array
/dev/md126p1 /media/Main        ext4    defaults        0       0

From /etc/mdadm/mdadm.conf:

# definitions of existing MD arrays
ARRAY /dev/md/Main metadata=1.2 UUID=c2ccbd00:ce414404:0ee05911:eebe2832
ARRAY /dev/md/Backup metadata=1.2 UUID=b4973c41:e735e1c0:29e8be4b:4fe7c007 name=:Backup

Whoever can answer me this small question gets the bounty: What is the best way to mount the backup and the main in a guaranteed stable way.

--edit--

/dev/md/Backup:

    Version : 1.2
Creation Time : Sun Jun 19 15:45:35 2011
 Raid Level : raid0
 Array Size : 3907021824 (3726.03 GiB 4000.79 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Sun Jun 19 15:45:35 2011
      State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

 Chunk Size : 512K

       Name : :Backup
       UUID : b4973c41:e735e1c0:29e8be4b:4fe7c007
     Events : 0

 Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       81        1      active sync   /dev/sdf1

/dev/md/Main:

    Version : 1.2
Creation Time : Sun Jun 12 02:13:25 2011
 Raid Level : raid5
 Array Size : 3907021568 (3726.03 GiB 4000.79 GB)
Used Dev Size : 1953510784 (1863.01 GiB 2000.40 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Mon Jan 28 19:00:45 2013
      State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

     Layout : left-symmetric
 Chunk Size : 128K

       Name : :Neue RAID-Anordnung
       UUID : c2ccbd00:ce414404:0ee05911:eebe2832
     Events : 17846

 Number   Major   Minor   RaidDevice State
   0       8       49        0      active sync   /dev/sdd1
   1       8        1        1      active sync   /dev/sda1
   3       8       65        2      active sync   /dev/sde1
share|improve this question
    
Do you maybe use snapshots or have a backup utility that restores data? –  Martin Schröder Jan 26 '13 at 22:21
    
@MartinSchröder Thanks for your replay. There is no backup utility running (I do the backups by hand at the moment). AFAIK ext4 doesn't support snapshots (I don't use lvm). –  JustMaximumPower Jan 27 '13 at 10:04
    
Can you please provide your mdadm --detail for the above RAIDs? Why aren't you just mounting in /etc/fstab /dev/md/Main & /dev/md/Backup? –  slm Jan 28 '13 at 16:38
    
not using /dev/md/* was exactly the error. I believe that the /dev/md* labels are given to whatever superblock is detected first. So you agree that using /dev/md/* labels works as expected? –  JustMaximumPower Jan 28 '13 at 18:13
    
I've always used the /dev/md* labels when mounting RAIDs. The only other difference I can see is that I make use of LVMs on top of my /dev/md*. But that isn't mandatory. –  slm Jan 28 '13 at 18:44
add comment

2 Answers

The best way is to mount using UUIDs, in your fstab:

UUID=c2ccbd00:ce414404:0ee05911:eebe2832 /media/Main ext4 defaults 0 0
UUID=b4973c41:e735e1c0:29e8be4b:4fe7c007 /media/Backup ext4 defaults 0 0

As pointed out by @Floyd, using labels is also nice, since you could create a new device with the same data and the same label if you need to change things. So you can do

tune2fs -L RAIDMain /dev/disk/by-uuid/c2ccbd00:ce414404:0ee05911:eebe2832
tune2fs -L RAIDBackup /dev/disk/by-uuid/b4973c41:e735e1c0:29e8be4b:4fe7c007

and then in your fstab:

LABEL=RAIDMain /media/Main ext4 defaults 0 0
LABEL=RAIDBackup /media/Backup ext4 defaults 0 0
share|improve this answer
1  
UUID is definitely the way to go, unless you want to give your partitions names. –  Floyd Jan 31 '13 at 8:13
    
I had to use the UUID of the file system and not of the array. But other then that its dead on. I used sudo blkid to find out the UUID of the partitions. –  JustMaximumPower Feb 1 '13 at 18:04
add comment

As I said in my comment to the OP, all you need to do is just use the paths that were declared in the /etc/mdadm.conf file. You can use the UUID or LABEL, as @Stefan Seidel mentioned, but they're not really necessary.

Sample /etc/mdadm.conf

ARRAY   /dev/md0  level=raid1  num-devices=2  UUID=37d3cabc:42393031:23c133e6:3b879f08
ARRAY   /dev/md1  level=raid5  num-devices=3  UUID=47d4cabd:42393031:23c133e6:3b879f99
MAILADDR root@krycek,root@byers,root@frohike

Sample /etc/fstab

/dev/md0      /export/raid1           ext3    defaults        1 2
/dev/md1      /export/raid2           ext4    defaults        1 2
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.