Raid 1 - any "soft" way to verify content present in both HDDs?

Support
1

Background:

My previous Raid 1 array (drive T1 and T2) degraded due to 1 single disk failure (T2).
To prevent data loss, I backup the content of the Raid 1 array onto another HDD, before I deleted the Raid 1 array and rebuilt.

So my steps were:

  1. unmount Raid 1 array
    umount /dev/Raid1

  2. stop Raid 1 array
    mdadm --stop /dev/md/Raid1

  3. remove Raid 1 array - this step reported “no device found”.
    mdadm --remove /dev/md/Raid1

  4. remove superblocks - and I guess this step deleted all array information?
    mdadm --zero-superblock /dev/sdc1 /dev/sdd1

  5. verify Raid device removed - and yup, nothing found.
    cat /proc/mdstat

I then proceeded to remove the faulty drive (T2), and replaced with a working drive (S1).
At this point, I also presumed that although raid info has been removed in step (4), the data should still present in disk T1, and thus, I went ahead to format the disk T1 using Gnome Disk, and I also run some partitioning using KDE partition manager. All these “plays” should sufficiently delete the data.
Finally, I setup new Raid 1 array again.

  1. I used fdisk to prepare the disks, and chose 43 (ie. Linux raid partition type) for both disks.

  2. Setup raid array
    sudo mdadm --create /dev/md/NAS1 --level=mirror --raid-devices=2 /dev/sdc1 /dev/sdd1

  3. The cat /proc/mdstat showed that raid1 is active, and the array was syncing.

  4. Again, sudo mdadm --detail /dev/md/NAS1 showed that State: clean, resyncing

So, it seemed like the process was successful, and I should have the new Raid 1 array ready to use.

Then, what’s the problem?

When I opened Gnome Disk, the new Raid 1 array showed the old partition layout from the old array.
After running Step (4) to zero the superblock, and after multiple formating of disk T1, I have not expected the partition layout to preserve, nor any data inside the old raid.

Yet, it was there.
I compared the file numbers, file size, etc, with my backup copy, and none is missing.
Eventually, I proceeded to delete the partitions of old layout, and re-partitioned the new Raid 1 array.

So now I have questions:

a. How did the old partition layout and the old data survived mdadm --zero-superblock and Format disk in Gnome disk, as well as KDE Partition Manager? Did I miss some step in order to wipe clean both Raid metadata and partition data?

b. My current raid status is:

/dev/md/NAS1:
Version : 1.2
Creation Time : Wed Nov 1 00:13:53 2023
Raid Level : raid1
Array Size : 5860389440 (5.46 TiB 6.00 TB)
Used Dev Size : 5860389440 (5.46 TiB 6.00 TB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

 Intent Bitmap : Internal

   Update Time : Thu Nov  2 22:03:55 2023
         State : clean 
Active Devices : 2

Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : bitmap

          Name : Me:NAS1  (local to host Me)
          UUID : 51212013:ab23ed1a:1623a31b:49fa0083
        Events : 6805

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1

Apparently the new Raid 1 is functioning.
But after the persistent old data issue, I’m running a bit paranoia - is there any “soft” way to verify the new data is present on both HDDs, ie. without removing the cable/HDD?

Appreciate your input!

2

Since it’s RAID1 I guess you could try mounting that HDD as a single, regular disk.

1 Like
3

If you are asking if the 2 raid drives are mirrored, above comment might work.

If you are asking if the data became corrupted, you could try a --dry-run with rsync and see if it wants to copy something. But that assumes the corruption happened AFTER you made the backup from hd1

1 Like
4

I think no !

This is the point at which modern software raid is clearly superior to previous hardware raid. For example, if btrfs is run as a raid, there is

  1. Checksums for each block that reveal what is corrupt.
  2. The ability to initiate a repair from the running system. The software can recognize the undamaged block by the checksum :wink:
  3. The possibility of having all data read (scrub)
  4. The ability to mix different drive/partition sizes (replace a broken drive with a larger new one)
  5. A low-risk (and low-stress) switch to the new drives in the event of a defect.

see also:

:footprints:

5

Is op using btrfs though? There is no mention about it… xD

6

You mean to remove the new Raid array, and mount each HDD respectively, in order to check the data?

No, my question is not about data corruption.
Pls see my question section.

Thanks.
Not considering btrfs cuz I need the data to be compatible with Windows.
But from your reply, I presume there is no “soft” way to verify the data is present in both HDDs, and it can only be done the “hard” way, ie. remove 1 HDD and reboot?

I’m using NTFS.

7

Then why are you trying to do a check? If there has been no corruption (missing files f.ex) then the files are not changed.

That’s… not great on linux. ntfs is proprietary to microsoft, the drivers are not supported on linux, just so you know. There is no source code available from microsoft.

But with your attitude, I’m backing out.

8

No need to remove anything if you boot live iso.

1 Like
9

I tried boot live iso.
Dolphin showed the partitions in superblock, and not the partitions in each HDD.

I also tried to boot into Windows, but Windows Explorer unable to display the partitions - probably due to the partitions being setup as “Linux Raid Partition” in Step (1) of setting up raid.

So I still have no “soft” way to verify the data.

10

Well, I never said it will work. :stuck_out_tongue: Not sure if because of NTFS or just because whatever.

11

In my 1st post, I asked:

And your response:

I wondered when I asked if the data became corrupted.

And despite that I mentioned:

You went on to make irrelevant assumptions:

I did not want to write my post again to answer your questions and assumptions, and I “inoffensively” request you to refer to my 1st post.

And then, comes your attitude:

Do you always blame others for your “i-dun-read-your-post, and-it-is-ur-fault” attitude?

I do appreciate every guru who spend time to read my post and provide valuable input, but not those who step in and try to flame a war.

Kindly spend your “valuable” time elsewhere.
Thanks.

12

It’s a good try, nevertheless.

On a separate thought:

Since the “Linux Raid Partition” setting is required by mdadm to setup Raid in Linux, and this “Linux Raid Partition” is not recognised in Windows (I have not tried WSL yet), then there is no point to partition the superblock as NTFS?

Or is there an alternative approach to create a software Raid 1, that is accessible in both Linux and Windows?

13

Honestly, I have as much clue as the next guy. :stuck_out_tongue: The only raid I’m using on linux is zfs’s.

I’m not sure how can you partition a superblock as anything. :man_shrugging:

14

My bad.
I got confused - each HDD is formatted as “Linux raid partition”, before assembled into Raid array.
image

But the Raid superblock, is partitioned as NTFS.
image