This is a bit overkill for a daily backup system. In almost all cases I would prefer to use cron over Kala for a backup script. You get some great and useful benefits for using Kala (metrics, logging, better real-time controls and monitoring), but it is still way overkill for such a simple task.

Nevertheless, I want to be able to start using Kala in production for something out-side of ETL and application logic. I know that it has its place in systems management, but I hadn’t prototyped a way to do so yet. Also, I needed an execuse to write something in Ruby, as I am starting at a Ruby on Rails company this upcoming week.


  1. Kala
  2. Systemd service file for Kala
  3. tarsnap-scripts

The backup script

You can find the code for this here:

The code for this backup script is fairly simple. It utilizes a config.json file in the same directory to provide the user-set options. You can find an example config file in the repo linked above.

# Backup script for ajvb's laptop using tarsnap and Kala for scheduling.
require "json"

if __FILE__ == $0
    config_hash = JSON.parse("#{File.dirname(__FILE__)}/config.json"))

    config_hash['dir_list'].each do |target|
        # Extract "target_name" from target.
        # "/home/ajvb/.myfile/ -> "myfile"
        target_name = target.split(File::SEPARATOR)[-1].gsub(/\./, "")

        # Example: "backup-bashrc"
        backup_name = "backup-#{target_name}"

        cmd = "tarsnap -c --cachedir #{config_hash['cachedir']} --keyfile #{config_hash['keyfile']} -f #{backup_name} #{target}"
        puts "Backing up #{target}"
        resp = system(cmd)
        if !resp
            puts "Error with backing up #{target}"


Installing and Deploying Kala locally

You can find more complete installation information within Kala’s README.

Right now, there are no binary releases. The easiest way to install Kala is:

go get

Below is taken directly from the systemd folder within Kala’s repo

Here is the simple service file for Kala that I use:


ExecStart=/home/yourname/bin/kala run -v -p 8000


Once you have that file, you need to set it up within systemd.

  1. Save the above config as kala.service
  2. Make sure to change the path to your kala binary in ExecStart (within the kala.service file) to where it is.
  3. Make sure to change the port in kala.service’s ExecStart to what you want it to be. (Defaults to 8000)
  4. Move kala.service to /etc/systemd/system/
  5. Run systemctl enable /etc/systemd/system/kala.service
  6. Run systemctl start kala and then systemctl status kala to verify that it is working properly.

A more complete systemd guide can be found here: Getting Started with systemd

Adding the backup script to Kala

You can find the code for this here:

The script I used is based off of the example ruby script in Kala’s main repo. It’s fairly simple.

One thing to note here: This script assumes that Kala is listening on port 8000.

If you want it to run less or more frequently, change the schedule value in the data variable in the script below.

# Based off the example ruby script in Kala's main repo.

require 'net/http'
require 'time'
require 'json'

def post_to_kala(data)
    req =
    req.body = data.to_json
    res = Net::HTTP.start(, API_URL.port) do |http|

    if res.body

data = {
  name: 'tarsnap_backup',
  command: "ruby #{Dir.pwd}/backup_laptop.rb",
  epsilon: 'PT5S',
  schedule: "R/#{( + 120).iso8601}/P1DT"

puts "Sending request to #{API_URL}"
puts "Payload is: #{data}\n\n"

job_id = post_to_kala(data)['id']
puts "Job was created with an id of #{job_id}"

Wrapping Up

This was a fun way for me to learn a little bit about Ruby and Systemd. Next up, I want to expand upon various ways I am utilizing Kala within my own personal machines for systems management.

Hope this helps.