From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Local network backup
Date: Fri, 14 Sep 2007 18:51:26 +0000 (UTC) [thread overview]
Message-ID: <pan.2007.09.14.18.51.25@cox.net> (raw)
In-Reply-To: 200709141303.46235.prh@gotadsl.co.uk
Peter Humphrey <prh@gotadsl.co.uk> posted
200709141303.46235.prh@gotadsl.co.uk, excerpted below, on Fri, 14 Sep
2007 13:03:46 +0100:
>> That said, backing up your personal data to it seems like a not very
>> good idea. Were you planning on encrypting it or something?
This is what disturbed me about the idea as well. Ideally, you keep
everything personal off the firewall, and at a slightly less priority,
don't depend on it for anything you might run that could be rooted (thus
killing the idea of system backups).
> I see what you mean, but really the main use of the backup would be to
> recover a working system to a damaged box (I can be just as clumsy in
> admin as anyone else), rather than spending a week or more rebuilding it
> from source. User data could perhaps be backed up elsewhere - I have a
> handy little USB disk that would do nicely.
Well, keeping user data elsewhere is a good first step, but consider what
happens if you have to use that system backup and it has been rooted.
Are you willing to risk the integrity of that data any more than your
personal data? What will have been the value of storing the personal
value elsewhere if you now restore it to a system rebuilt from possibly
rooted data?
>> Is there a wireless router thrown in there somewhere?
>
> The one wireless link is between the laptop and an access point; the WAP
> is connected to an Ethernet switch which lives between the workstation
> and the gateway. Why do you ask?
Strictly speaking, anything transmitted over the air should be considered
the same as transmitting it over the Internet in general -- IOW, keep the
AP outside the firewall, or in a DMZ behind an initial firewall/router
and an inside one protecting the wired network upon which you put
anything you'd not want exposed to the Internet in general. *OR* encrypt
anything transmitted over the wireless to the same level you'd feel
comfortable with were it transmitted over the Internet. If you are sure
you trust the WEP or whatever of the wireless to the same level you'd
trust your encrypted banking session, well, you can send your banking
info over it, otherwise... Because once it's on air the wise thing is to
simply assume that someone's listening in, just as is the case with the
Internet. If it's encrypted to your satisfaction, great, if not, assume
it's now publicly exposed info, because it's possible it is.
...
For system rebuild scenarios, I use FEATURES=buildpkg here, and then
periodically backup my packages dir (which is also on my main system's
RAID-6, for a bit of redundancy at that level, tho that won't of course
protect from fat-fingering or the kernel-rc I decide to try that has a
bugged md/raid that scribbles gibberish all over my previously working
RAID). That gives me binary packages of everything should I need to
rebuild, so it shouldn't take a week, tho it'll take a few hours. Of
course, a backup of /etc and other INSTALL_PROTECT dirs should be made as
well, so you don't have to reconfigure everything. Private data backups
are a bit different.
For the reasons explained above, I'd not be comfortable putting backup
data on a firewall machine -- at least not unless I had it checksummed or
signed to detect tampering (which handily detects in-transit and in-
storage corruption as well =8^), with those checksums stored elsewhere,
say on a USB key or the like.
What I'd suggest these days would be backing up the config and anything
private from the laptop onto the desktop, then using an eSATA (external
SATA, the connection's about the same but the connectors speced to be a
bit more robust, but you could use standard SATA if you were careful)
drive attached to it to backup its private data and config, plus the
shared package data (you don't need to backup the laptop's data from it
however, as one would hope you don't lose both the laptop and the desktop
at once). Keep the external drive unplugged except for the once weekly
or whatever that you do the backup. If you are really paranoid, do the
two separate sets thing, alternating full backups so you have the
previous week's backup if you lose both the machine and the external disk
during a backup session.
The beautiful thing about hard drive media backups is that you can pretty
much simply copy all your data over just as it is, not worrying about
fancy backup formats or whatever. To restore, you just copy it back, and
if you have it setup right and you chose your hardware and kernel etc
config with this in mind as well, you can even boot the backup itself and
have a fully working system to work in while doing the restore.
I recommend SATA/eSATA because the bus speeds are higher than USB 2.0 and
Firewire 400 (Firewire 800 is getting there, of course the drive itself
may not be any faster than USB 2.0 anyway, but it doesn't hurt), and they
don't incur the protocol transfer overhead that the USB/FW stuff does --
depending on the hardware you choose for implementation, you may be able
to use the same kernel hardware drivers you use for your standard
internal storage, yet they have all the convenience of pluggable external
drives! =8^)
Here, I'm actually looking at the possibility of plugging in external
eSATA based 5:1 port-multiplier-ed boxes for my next RAID upgrade, tho
it's wish-list more than anything else at this point. The other
alternative is to remain internal, but switch to 2.5" drives using
available 4/5.25" drive bay multiplexers. I've four such bays available
for hard drive use in my full-tower, which would allow for 16 such drives
(I'd obviously use port multipliers there as well). If I reserve two as
hot-swap and use RAID-6 with its two parity-stripes, that'll give me a
12-way data striped RAID array, which should be reasonably fast even at
the slower speeds of 2.5" drives. Still wish-list, tho, and I expect
it'll be another couple years before it moves off wish-list status.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-amd64@gentoo.org mailing list
next prev parent reply other threads:[~2007-09-14 19:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 9:22 [gentoo-amd64] Local network backup Peter Humphrey
2007-09-14 11:26 ` Hamish
2007-09-14 11:42 ` Peter Humphrey
2007-09-14 13:17 ` Peter Humphrey
2007-09-14 13:34 ` Jordi Molina
2007-09-14 14:24 ` Etaoin Shrdlu
2007-09-14 14:31 ` Jordi Molina
2007-09-15 7:52 ` Peter Humphrey
2007-09-15 9:19 ` Etaoin Shrdlu
2007-09-15 10:21 ` Peter Humphrey
2007-09-15 10:43 ` Etaoin Shrdlu
2007-09-16 12:08 ` Peter Humphrey
2007-09-16 14:10 ` Etaoin Shrdlu
2007-09-14 16:10 ` Jack Lloyd
2007-09-14 16:32 ` Mike Williams
2007-09-14 16:41 ` Jack Lloyd
2007-09-14 16:38 ` Steve Herber
2007-09-17 9:34 ` Hamish
2007-09-14 11:29 ` Wil Reichert
2007-09-14 12:03 ` Peter Humphrey
2007-09-14 16:01 ` Wil Reichert
2007-09-14 18:51 ` Duncan [this message]
2007-09-15 12:39 ` Volker Armin Hemmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2007.09.14.18.51.25@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox