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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
