(NOTE: This is the second of a three part series on setting up a cloud-based backup system, and describes how to use the various technologies discussed previously. The first describes criteria and reasoning for the various technologies selected for use, while the third describes setting up the backups to run automatically on schedule.) Setting Up “restic” “restic” is the the backup technology we will use for its performance, deduplication, and native support for writing to various different remote backends.
(NOTE: This is the first of a three part series on setting up a cloud-based backup system, and describes the rationale behind the various technologies selected for the system. The second describes how to setup and use the backup system, while the third describes setting up the backups to run automatically on schedule.) Introduction This is a series of three posts that describe how to set up a modern, performant, efficient, and economical cloud-based backup system on your machine.
In the world of Richard Morgan’s Takeshi Kovacs series of books, individuals record their psyches to “cortical stacks” integrated into their bodies, which allow for them to be resurrected into alternate bodies should their current bodies fail or be destroyed. This can only be done if the cortical stacks themselves survive the body’s destruction. The very rich and privileged backup their cortical stack information to remote digital storage farms so that they can be restored even if their cortical stacks get destroyed.
In a previous post, I discussed some of the different options available to you on most POSIX system to automate the running of jobs on schedule. Here is a brief recipe on how to actually use the modern/trendy and actually functionally beneficial “systemd” to do this as a normal (non-root). In addition to the job file or script itself, you will need to create two files: a timer file and a service file (also referred to as timer unit and service unit).
Today, you generally have three choices for a time-based system scheduler: “Cron”, “anacron”, and “systemd”. There is a lot of information out on the web about these, so here I shall just summarize the basics from a practical standpoint to answer the question “which scheduler/timing system should I use?” “Cron” is the traditional timer. It is available everywhere, and tried, tested, loved, and it just works most of the time for most people.
Sometimes I use a touchpad, and at other times an optical mouse, but my main workstation pointer device is a trackball, in particular, the Logitech M570. This model comes with two little index finger buttons, labeled “Forward Button” and “Back Button”, in the image below: which by default send you forward and backward through your web page visit chain in your browser. I find this mapping a phenomenal waste of two very useful buttons.
End of an Era The great experiment is over: After almost a decade of OSX, I have now returned to Linux: My foray into the world of OSX/macOS was good for most of its run, and, at its height, it was simply brilliant. When I first adopted OSX (after half a decade of running Linux), it was the ultimate developer experience. Not just the perfect balance between developer power/functionality and user bell-and-whistles, but actually as good as the best at both.
My SSH key-based authorization kept failing on a private GitHub repo on a remote machine, even though my SSH keys for that machine were properly registered on the GitHub account. The solution was to force the “git” protocol instead of “http”. That is, instead of: url = https://github.com/accountname/reponame.git use: url = firstname.lastname@example.org:accountname/reponame.git in your “.git/config: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git@github.
This one’s simple. Just disable the GUI and solve two problems at once. ./configure --without-tcltk \ --prefix=$HOME/Environment/local \ && make && make install
In contrast to the simple single-line nicely-behaved “git submodule add” command, removing a submodule requires you to: $ git submodule deinit -- path/to/submodule $ rm -rf .git/modules/path/to/submodule $ git rm -f path/to/submodule $ git commit -a -m "Remove submodule" Apart from the multiple steps with “rm -rf freely being tossed around willy-nilly, note the second command where you manually fiddle with the guts of the repository structure. That does not get propagated up to any remotes in a push or any repos that pull from you or a shared remote.