Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
