Use caution on the RAID-5
see RAID topics
MS Planning and another set of
Considerations
excerpt from
Neopapsis
=====
If you had four drives, I'd suggest doing a RAID 0+1 (mirror +
stripe) logical volume, which would get you maximum speed and decent
reliability. You want to avoid RAID 5 if at all possible, unless you
can be absolutely certain that the resulting device is still faster
than your machine, because RAID 5 typically sucks for writes.
Note, if you do RAID 0+1, you want to stripe the mirrors and not
mirror the stripes. If you mirror the stripes and you lose one disk,
then that stripe is unavailable and that causes the mirror to be
degraded. If you stripe the mirrors and you lose one disk, that
mirror will be degraded but the stripe should be fine.
=====
Back to the backup/replication question.
Backups (and disaster planning) is a CYA activity; You're likely to never need it,
but if you do, boy oh boy, it sure pays for itself. If this premise is true, then
all the effort is actually WAISTED (keep reading). To lessen the overhead losses,
you want to move as much CYA costs off the OLAP (online application processing) systems.
If you fully implement the co-location site (a full duplication of the OLAP,
capable of resuming business at a moments notice), then
REPLICATION is the fundamental tool, it's overhead is the OLAP impact,
and you can defer the cost of
BACKUP to the co-location system
Replication: this needs to be frequent and only recently modified data
(similar to an incremental backup). This will reduce the amount of data being
replicated and thus the impact of doing so. IF the size of the replication
becomes so large that as soon as one cycle completes another starts, you
then change the frequency by 1/2 of whatever it currently is which will
idle the replication system by the 1/2 not used.
Systems day-to-day operations:
Biggest usage of a backup image is to reclaim user errors, eg:
a) I erased the wrong file, b) we need to rollback to last weeks A/P, ...
This makes two points:
1) application backup is <> (not the same as) systems backup
2) you will need to access the CYA data more than originally considered when
creating the disaster plan. No one would do a full systems restore for either
of these case, would they? {hint: no system availability at all until complete}
Instead, the file (a) would be pulled from the image and then appropriately
relocated. The A/P (accounting en total ) system would have its own image
and that would be used {impacting accounting but no one else}
Systems and Techniques:
You made no metion of the OS, and while I could deduce like candidates from
the Retrospect and Replistor references, I'm going to keep this as general as possible.
In the dark ages of 8086, 80030, and even mainframes, Backup was brute force
copy record 1, track 1, cylindar 1, record 2, track 1, cylindar 1 ... ad naseum(sp?)
Every backup of the same size HD took exactly the same time, and faithfully
copied even EMPTY blocks to the backup media (real dump hey).
This was a
physical backup. Today, GOOD systems use a
logical backup;
copy file data, not HD blocks. An HD with only a few files will backup at light speed
The side effect is also a backup that is more portable, ie can be restored to
a different sized
logical disk.
Backups today should be focused upon Logical Volumes or
partitions(file systems), not physical disks. This will allow resizing the data store
to make more free space, as well as defragmenting it when restored
(another use of backups).
{note to moderator: hum; kind of lengthy. Free free to off load as an attachment, but if left in-line, it should be searchable }
