This is Part 4 of my series on building a restic-based system backup series. The rest of the articles can be found here. Replication A goal from the start of this project has been replicating backup date to multiple locations. A long personal and professional history of dealing with backups leads me to the mantra that it isn't backed up until it's backed up to three different locations. Restic has several features which make this easy: backend storage (to a first approximation) is treated as append only — a blob, one stored, is never touched although may be deleted as part of expiring snapshots.
The standard end-of-the-year party and eating season conspired to keep me from much creative work here, but I've been off work this past week and managed to wrap up a new issue of Late Night Thinking and do some work on my restic systems backup setup. Both will appear here shortly. Also, if you're one of the small number of people who haven't found this out from any number of places, on 1 November 2016A I got engaged to E, my boyfriend of two years.
This is Part 3 of my series on building a restic-based system backup series. The rest of the articles can be found here. We've got enough things setup that we can start backing up a client system. We'll do this in two sections: setting up the server side, and setting up the client side. Setting up the backup server side Using 'new-restic-server' to set up the server You can find new-restic-server in the git repo.
This is Part '2.5' of my series on building a restic-based system backup series. The rest of the articles can be found here. You should be reading Part 3 here, but in the development of that, I ran into this restic bug: Unable to backup/restore files/dirs with same name. Unfortunately, for historic reasons (buried in some of the oldest code in restic), only the last component of a path being backed up in a restic repository is reflected in the repo.
Part 2 of my series on building a restic-based system backup setup. Part 1 can be found found here. As described in Part 1, my general strategy is to have a centralized backup server at a particular location, running an instance of minio for each server being backed up. In essence, I'm going to want to be running N minio server --config-dir=/... instances, and I want a simple way to add and start instances, and keep them running.
I might write this up as a full tutorial someday, but there's already a few of those out there. That said, here's a short outline of my current usage of PGP, aided by modern GPG and the OpenPGP smartcard functionality of a Yubikey 4. Use GnuPG 2.1. Private keys are stored in a .d directory, can act as an ssh key agent, and you can forward your local gpg-agent to a remote server.
This is the first in what will undoubtedly be a series of posts on the new restic-based system backup setup. As I detailed earlier this week, I've started playing around with using restic for backups. Traditionally, I've used a variant of the venerable rsync snapshots method to backup systems, wrapped in some python and make, of all things. Some slightly younger scripts slurp everything down to a machine at home so I've got at least another copy of everything.
A long weekend (here in the US) combined with a few strategic days off, and I had a long, five day weekend. A few of those days I managed to get out of the house and down to a coffee shop, so I got a bit of work in, and managed to wrap up a bunch of techno housekeeping. First, with a new laptop and a fresh VM install of Debian 9, I've got all the components in place to reach my ideal PGP setup ‐ my day-to-day keys are on a Yubikey 4, ssh can now forward unix domain sockets, and gpg has well-defined socket locations for the agent that deals with keys.
Bae and I both got addicted to Yuri on Ice when it came out, and when picking a costume for Flame Con, bae picked Yuri. He wanted to have ice skates in the costume, and so I put a bunch of thought into how we could make ice skates something that would be walkable. Eventually I decided that I'd embed the blades of iceskates in a plastic resin block with some sort of sole attached to it.
tl;dr: If you're trying to follow Kenn White's My $169 development Chromebook and the Google account you're using on the Chromebook is associated with a Google Apps For Your Domain domain, there will be ... issues. You'll quickly discover that at the "Turn on the Play Store" step, doing that for GAFYD domains is controlled by your domain administrator. I happen to be my domain administrator, and I quickly fell into a morass of device management and device enrollment and licenses and and and.