DSM-G600, DNS-3xx and NSA-220 Hack Forum

hawse, you are bringing up some very good questions ...
Your data is important to you, and if something would happen, like a hard
drive failure, you want to be sure to be sure you can recover your data.

One of the best ways I know of determining the correct disaster recover procedure, is to
simulate the failure and prove to yourself you can recover your data  to your satisfaction.
This is failure simulation is best done before the unit is put into general service.

I see you only have 2% of your 750 disks used, so now would be a good time (I would think)
to formulate (and practice) a disaster recovery procedure.

There are three partitions on each of your drives

/ # fdisk -l /dev/sda

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1          66      530113+ 82 Linux swap
/dev/sda2             131        9729    77103967+ 83 Linux
/dev/sda4              67         130      514080  83 Linux

Your data is contained on the /dev/sda2 (or /dev/sdb2 for the second disk) partition.  There is a
software RAID package called mdadm which is used to create the RAID1 (in your case) array of
/dev/md0 consisting of the two partitions /dev/sda2 and /dev/sdb2.  The /dev/md0 RAID array is
then mounted to the /mnt/HD_a2 directory

If you do a Google search on mdadm you will find many tutorials, there are mdadm commands which
will let you (in a telnet session) mark one of the raided partitions as failed and remove it from the array.
Then re-mount that partition to the /mnt filesystem and look at the files.  You can then un-mount and
rejoin that partition to the RAID array, wait for rsync.  Then do the same for the other partition.  You can't
un-mount the RAID array completely since your telnet session is running from that filesystem.  One way
around this limitation is to run your fun_plug scripts (and thus the telnet session) from a USB drive, this
will allow you to un-mount the RAID array and even fsck this array.

These are all good skill to learn; however, I think (?) you are probably more concerned that your data can be
recovered than wanting to learn the details of mdadm.  So, just simulate a disk failure.  First backup any data that
you feel is important, then shutdown the DNS-323 and pull one disk.  Restart the DNS-323 which will run in degraded
RAID1 mode.  Then wipe the pulled disk clean (remove any partitions) like it was a fresh replacement drive.  Shut down
the unit again and insert the clean disk.  Power up again and verify your DNS-323 return to a working RAID1 array.

Another thing you could try... before you insert the cleaned disk, power down the unit... remove the drive the was "simulated"
surviving disk and attach the disk to a XP system using ext2IFS (www.fs-driver.org) to backup your data.  This should give
you a procedure to backup the data before attempting the RAID rebuild.

As you think about different failure scenarios and recovery procedures, you might come to the realization that RAID1 is NOT
really a complete backup strategy.  It is designed for (and is very good at) keeping your data available in the event of a disk
failure.  However, it can not help you if you experience data corruption due to virus or accidental user deletion of files, becasue
the file corruption is instantly replicated over both drives, nor will it help you if you need to restore a previous version of a file.

RAID1 coupled with backup strategy, like copy (or rsync) to a tape drive (or other hard drive) can increase the probability you will
will be able to recover you data in a wide variety of failure event.  And knowing your data is stored somewhere else (besides the
RAID1) may help to ease your concerns that the RAID1 is truly mirroring your data.

Last edited by mig (2008-04-29 19:21:10)