So I'll chime in with the others here, there are two separate threats you need
to worry about here.
1. hardware failures.
This is where RAID will help, but realisticly, the fan and
power supply are about as likely to fail as the drive, so I'm not sure RAID is
really worth it here.
2. system corruption (aka user error :-)
RAID will not help here, you need a way to recreate the system from scratch. If
you have such a mechanism in place, then a dead drive becomes a pretty simple
"put in a new drive and recover" item.
there are several ways to approach this, and if I was doing it, I would look at
a two-tier approach along the lines of:
1. create a bootable CD/DVD image that will do a complete install with no
prompting other than "are you sure". This is not a distro CD. I would build the
system, with all tweaks/etc (including setting passwords, SSH keys, etc) and
then make an image of the result. The CD would partition the drive, dump the
image onto the partitions, install the bootloader, eject itself and instruct the
user to remove the disk and hit a key, at which point the system will reboot
into a usable state.
This is a last-ditch, "if they really mess things up or the drive dies, this
will get them going" recovery.
2. on the system, I would have a boot option to boot into a recovery mode. That
recovery mode would present the user with a list of restore points and overwrite
the main system partitions with the info from the selected restore point.
The base image that's created by the DVD would be one of the restore points.
Other restore points could be created by (with today's large drives you can
allocate a large percentage of the drive to holding such backups and not worry
about running out of space on the main system). I won't go down the rabbit hole
of discussing possible backup strategies on this list :-) I would not use LVM
snapshots or equivalent because one of the things I'm trying to recover from is
massive filesystem corruption and I wouldn't trust any snapshot mechanism to be
safe under those conditions.
Make sure the image includes some way for you to get into the system remotely.
This could be as simple as making sure SSH is open inbound through the router
from your systems combined with the system contacting a host you can get at logs
for when it boots up so that you can find what it's IP address is if it changes.
With this approach, it should be easy for anyone (including your 7
year old Granddaughter) to reset the machine back to what it was a week ago, or
a month ago before things went wrong. The worst problem this will cause is
loosing more recent documents (probably not a major issue for your granddaughter
for a couple of years, by which time she will know not to be careless about it),
and the fact that after a reset the system will be missing updates.
periodically you should make a new base image. This would be every 6 months,
year, two years, depending on the distro you are using and how you update it.
Personally, I would want to do a new base image every time the distro is
updated, so long term figure every 6 months or so.
Since the system will have an image of the base system as well as the most
recent backup, you should be able to do smart diffs between the two to find what
customizations have been made (first factor out files modified by package
installs/updates and apply those directly, then you can find what other files
have changed), If you have a similar system available locally, you can fully
test updates and merge in her customizations before sending them a new imaging
disk.
I would strongly consider using this mechanism to do the upgrades from one
distro release to the next as well.
Looking back at this e-mail, it looks like a huge amount of work, but if you
break it down into the individual things that need to happen, most of them are
fairly trivial. The only really hard thing is the idea of merging their updates
into a new base image, and that probably isn't needed for a 7 year old, but will
be desirable later on, so you have a few years to figure out those details ;-)
David Lang
On Mon, 18 Nov 2013, john boris wrote:
My reasoning for having the RAID system is I have to support this machine
(well hopefully I can teach my son) but computers break at the worst times.
I am just trying to save me time in rebuilding the unit. The unit is not in
my house so that is why I want this as fault tolerant as possible. But I do
have to keep price in mind. I'd rather spend a few bucks for some peace of
mind.
Suffice it to say that I am not worried that my 7 year old Granddaughter
will do something to break the computer. It is other people in the house
that don't understand. She understands what she can do and where she can go
on the net.
On Mon, Nov 18, 2013 at 10:05 AM, Josh Smift <iril...@infersys.com> wrote:
FL> I wouldn't consider RAID for a child's machine. I would have an OS
FL> that could be trivially installed.
That was what I was thinking, reading this thread: What are you going to
put on the kids' machine that's so important that you need RAID to keep it
running? I'd rather have a system that I can re-create trivially from
scratch. (For myself too, as it turns out. But especially for kids.)
-Josh (iril...@infersys.com)
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
