On 01/01/2014 16:33, Chris Davies wrote:
If the backup is really this important, I would strongly recommend that
you make additional backups elsewhere (offsite).
[....] I'd also suggest
that you replace the local singleton disk with a RAID1 pair.
I agree. Actually, the disk we are rescuing is the surviving member
of a RAID1 pair[1]. I realised, today, that I cannot simply install
that in our Wheezy box because (I think) it needs a software RAID
layer in order to read it (fstab refers to md1, md2 etc). But I can
copy the archive from where it is, over NFS, so I can still use the
suggested two-step migration scheme. So ...
The RAID1+LVM solution can be implemented as part of your migration to
a new server
OK. If we were to do this (and I think we ought to, we do have 2
spare 2TB drives), I've a couple of quick planning queries.
(a) Will Wheezy happily run RAID1 'only' on the 2 x 2TB disks, leaving
the OS on its non-RAID 250GB disk?
(b) More seriously, though, because we will need to expand the space,
there's only room on the motherboard for 4 SATA drives and to expand a
RAID1/LVM scheme I'll need another 2 drives, making 5 drives overall.
I'll run out of SATA ports. Happy to listen to any suggestions.
I had given this SATA ports issue some thought, though without
resolution. Current user reviews of 4TB drives are mixed, so I think
they are still a bit new. I'd like to stick with our 2TB devices, for
now. Maybe the bigger disks will be more solid in a year. A recent
posting on (I think) this list pointed to an Adaptec HW RAID card with
4 ports, which might solve the ports problem and let us expand to 2 x
2TB and (say) 2 x 3TB drives, albeit with some reconfiguration away
from software RAID.
But open to suggestions.
From an implementation point of view, presumably the steps are:
- Build a RAID1 layer on the 2 2TB drives
- Then build the LVM with pvcreate, etc,
regards, Ron
[1] We did try to rebuild the RAID1 but we couldn't get the rebuild to
work. The disks have multiple partitions, each is a separate RAID1 (I
think this isn't recommended) and while we were partitioning the
replacement disk, we ended up confusing mdadm. At the same time we
think there were some hardware issues because the (new) replacement
disk we inserted suddenly failed. At that point we decided it would
be safer to migrate the storage. Indeed, the story gives quite a good
example of why some offsite (or, at least, off machine) archive
storage would, as you say, add to our security.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c4730c.2060...@tesco.net