Los Angeles is earthquake country, plus a total loss of the home information resources is possible from fire. While we occasionally put a backup disc in our bank's safe deposit box, security of the box is not exactly absolute, particularly in an earthquake. We also have a fireproof box, which is believed to be fairly effective but which cannot be tested. An offsite backup server would give us a lot of peace of mind.
Ben may have partially agreed to let an offsite backup server onto his net.
Capacity requirements are modest, no more than 5Gb.
The backup procedure should happen automatically without manual intervention at either end.
Modern standards of security must be adhered to.
The server has to be small, unobtrusive and autonomous. Only very rare interventions needed from Ben, e.g. if he rewires the house.
It should not be a bandwidth pig.
It does not have to be accessible 24/7; scheduled wakeups are enough. But it has to be reliable, and self-healing after disruptions such as power failures.
Software maintenance has to be feasible from our end.
While the operating system is not an actual requirement, jimc has the expertise to do more with Linux, specfically OpenSuSE.
Possiblity #1: Ben's NAS box can act as a rsync server. Issues:
Possibility #2: On Ben's Windows machine he runs a rsync client to my host in L.A. (having a rsync server), and deposits the payload on his NAS box via SMB mounted on the client host, which is his normal mode of operation. Issues:
Possibility #3: I provide a box with Linux. Issues:
Possibility #3A: Ben would not do port forwarding, and the Linux box would initiate a VPN connection to L.A. IKE (IPSec) in general, and StrongSwan in particular, can re-initiate the VPN if it goes down, e.g. if the wild-side IP address changes or if the machine sleeps longer than the keepalive interval. This would be great except for an operating system upgrade, which if done remotely absolutely requires the master host to originate a SSH connection to the installer running on the target being upgraded.
Unless Ben thinks of something spectacular with Windows, it looks like the Linux box is the cleanest solution.
Ben needs to register his wild-side IP. Current plan: to give him ben.jfcarter.net through Dyn.com. His router is willing to register with www.dyndns.org (variants: custom, free, static). Requires the "A" record name, account name, and password. I'm to set this up and send him the info. This can be tested ahead of time.
Proposed hardware: CompuLab Fit-PC3 Basic
. $379, sold by
Compulab and fulfilled by Amazon. Specifications:
A better choice probably is the CompuLab Fit-PC3 LP Barebone, $275 sold by Compulab and fulfilled by Amazon. Specifications: Similar to above.
If getting the Fit-PC3 LP I'll need to get memory and a disc. I would get the same ones I have in Diamond (from Amazon). Actually, the current versions of the products.
giving SSD-like performancewith favorable access patterns. The 7200 RPM non-hybrid drive for Diamond is discontinued.
So the total price tag would be $401.
The SSH protocol can use a variety of crypto algorithms at each step. Currently with up-to-date versions at both ends, the initial key is synced by Elliptic Curve Diffie-Hellman key exchange. This is then used in the AES128-CTR algo with HMAC-MD5-ETM integrity checking. For mutual authentication the server has a ECDSA private key and the client has a saved copy of the certificate, and this particular client user has a RSA private key (2048 bits) for which the server has the certificate, or GSSAPI (Kerberos) can be used.
Here is the scenario for setting up and using this backup machine.
Soon, Ben would set up his router to register his wild-side IP address with Dyn.com (www.dyndns.org). He would also make sure that his CouchNet login and password are still functional. He would use these to get onto the backup machine.
At home I would set up the machine with OpenSuSE-13.1 and configure everything. Procedures would be tested locally.
The machine would be included in weekly software updates and backups. Access would be identical to a local machine, using the general SSH credential.
Ben would take the machine home after Christmas and park it on the shelf of his router closet.
The machine would sleep most of the time. It would wake at 09:00 daily and do housekeeping, then at about 09:10 Diamond would originate a connection to it using SSH with restricted execution, and would send via rsync the backup directory and the basic document cache.
The majority of these files do not change except in distro upgrades. Syncing them takes almost zero time. If a file did change, rsync has an efficient algorithm to identify regions of the file that aren't changed, and to not send them on the wire.
If I need to retrieve files I would use rsync, with my general SSH credential, and similarly if I need to do software maintenance.