public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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