Re: mdadm --monitor: need extra feature?

["Sergiusz Brzeziński" <Sergiusz.Brzezinski@supersystem.pl>]

W dniu 21.08.2012 14:39, Adam Goryachev pisze:
> On 21/08/12 21:51, Sergiusz Brzeziński wrote:
>>
>>
>> W dniu 21.08.2012 12:44, David Brown pisze:
>>> On 21/08/2012 12:41, Sergiusz Brzeziński wrote:
>>>> Hi,
>>>>
>>>> I use Raid1 to make backup of the whole system.
>>>
>>> Raid is not a backup system. It is to improve uptimes, minimise
>>> downtimes due to
>>> disk failures, and possibly to improve disk speed and/or capacity.
>>>
>>> I would recommend you first think about what you are trying to
>>> achieve here -
>>> what are you trying to back up, how do you see restores being used, how
>>> efficiently are you using your hardware, your bandwidth, your time
>>> and effort?
>>>
>>> You would probably be better off with a normal fixed 2-disk raid1 to
>>> minimise
>>> the problems caused by a single disk failure, combined with an rsync
>>> snapshot
>>> style backup that can be fully automated and give quick and easy
>>> recovery of
>>> multiple old versions of files in the face of the most common cause
>>> of data loss
>>> - human error.
>> [...]
>>
>> I know, I know. Raid is not a backup system :)
> Aside from RAID is not a backup, perhaps the more useful suggestion
> would be to use the right tool for the job...
>
> So, again, ignoring that you possibly should not be using RAID for a
> backup... how about using udev scripts to see when you plugin a drive,
> and that script can check the UUID against any md arrays, and if it
> matches, add it to the array....

I wrote a script making this work. It runs once a hour. I pass the parameter 
with md device to the script. It checks the state of the array with "mdadm 
--detail". If there is something wrong (State : degraded) it reads UUID of that 
array. Then it scans for /dev/sd* partitions and checks with "mdadm --examine" 
if UUID matches. If so, the partition can be added with "mdadm --add". That is 
why I asked abut this feature in mdadm - recognising if there is a new partition 
belonging to monitored array. With mdadm this procedure would work on elegant 
manner.

>
> BTW, I've used BackupPC (Linux based, free software for complete backups
> of linux + windows + pretty much any other OS, using hard links to
> de-dupe files), which would export the most recent backup of each
> machine and dump it as a plain tar.bz2 file onto external HDD, which was
> auto-detected based on the following criteria (which I decided was "safe
> enough"):
> 1) Matching the UUID to a list of known UUID's for backup drives in the pool
> 2) We could mount the first partition with a pre-determined FS type
> (mount -t ext3 blah)
> 3) After mounting, a specific file existed (if [ -f
> /mnt/archive/special_file ])
> If all that matched, then we would create a new archive for the first
> host, then delete any old archive for this host, repeat for all hosts,
> unmount, send complete report to monitoring system.
>
>
> Regards,
> Adam
>

Yes, that is probably good backup tool. (I don't know this tool, but I guess it 
is :) ). In both cases (my, and Your) we can change the hdd in hot-swap bay. The 
difference is (for me it is very importand difference) that in moment of 
removing disk, You have just a backup, and I have the backup + working, ready to 
use, with most up-to-date files, system. Ok, there can be some corrupted files 
(hot-swap removing can cause this) but that is the reason for making "real 
backup" of critical data independently of raid and storing it for example on the 
raid device itself! I do it for example with postgres database with pg_dump in 
cron. Then I rotate it with logrotate to have some more backups from the past. 
So, on my mirrored, just removed disk is the whole, probably ready for instant 
use, system. In case of problems (corrupted database indices or data files for 
example) I also have "real" backups on the disk from the past.

I don't want to argue, which solution is better. It can depend on many 
circumstances and needs. As we sad, "Raid is not a backup system" - so it 
doesn't have many features which real backup system have. I only want to say, 
that for me Raid1 is the excelent backup solution regardless of wheter I should 
use Raid1 for backup or not. Fortunately no one can prohibit using Raid on this 
way :) And I just choose the solution which works for me better.

best regards

Sergiusz
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html