Simple backup status

Simple backup status #

Currently running Back in time to backup one desktop machine at home. Smooth run, efficient, but have to check daily if the backup is ok or else. This is the problem to solve.

Architecture #

To start small I’m using Gatus,a developer-oriented health dashboard that gives you the ability to monitor your services using HTTP and other simple methods. Just let it know how often to call the endpoint and what values expect from the response body

1
2
3
4
5
6
7
8

    metrics: true
    endpoints:
      - name: website
        url: https://twin.sh/health
        interval: 5m
        conditions:
          - "[STATUS] == 200"
          - "[BODY].status == UP"

On the backup side Back in time offers user callbacks, basically a script that is called after or before each backup phase (backup start, backup end, on error and so), being it an interesting integration point

Given that Gatus erquires a REST to query for status and Back in time has no server to store it, the proposed solution is to make user callback save the last status for Gatus retrieval. Why saving last status only instead of results history? this will allow to check the point of failure and revert any change that caused it. Remember the simple solution goal. Back in time has its own log, then on error the GUI can be opened and checked, also Gatus maintains a status log (green on success, red otherwise). Then saving status is a waste of resources like development time (have to save data in store, make depuration process, and so)

Now the server part for status storing. Another simple solution I’m working with is n8n, a workflow automation platform for technical teams. A mix of point and click workflow builder with a lot of integration nodes plus glue logic to make it work the way you want. The proposed implementation contains two enpoints, one for Back in time status reporting (and saving) and a second one for status querying by Gatus

Implementation #

Let’s start with n8n and status reporting and querying

The Status report endpoint receives a POST request where the backup status and message is expected (as especified by Back in time user callbacks) and stores them plus the current timestamp (Save last execution node). To keep it simple no database is used but storing the results in memory. In case n8n is restarted and data is lost the verification will fail (no data). Checking for backup failure in this case is my B plan. I can live with this design flaw

For status querying the Status query webhook is used which calls Get last execution code which verifies that the backup has been taken in the last 24 hours and status code is 3 (everything is fine)

Going to Back in time implemented a simple script that call the n8n endpoint on each backup phase to report status

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#!/usr/bin/env bash

profile_id="$1"
profile_name="$2"
reason="$3"
backup=n8n-hostname-here
report_webhook=http://${backup}/webhook/9eb080ff-1aba-4efb-9755-e708d15efe66

case $reason in
    1) #Backup process begins
        ;;
    2) #Backup process ends
        ;;
    3) #A new snapshot was taken
        snapshot_id="$4"
        snapshot_name="$5"
        curl -v ${report_webhook} \
		      -H "Content-Type: application/json" \
  		    -d '{"status": 3, "message":"A new snapshot was taken"}' 
        ;;
    4) #There was an error
        errorcode="$4"
        case $errorcode in
            1) error_message="The application is not configured"
              ;;
            2)  error_message="A 'take snapshot' process is already running"
              ;;
            3)  error_message="Can't find snapshots folder"
              ;;
            4) error_message="A snapshot for 'now' already exist"
              ;;
        esac

	      payload=`echo '{"status": 4, "message":"'$error_message'"}'`
        curl -v ${report_webhook} \
          -H "Content-Type: application/json" \
          -d "$payload"
        ;;
    5) #backintime-qt4 (GUI) started
        ;;
    6) #backintime-qt4 (GUI) closed
        ;;
    7) #Mount drives
        ;;
    8) #Unmount the drives
        ;;
esac

Finally the Gatus configuration. Just add the new endpoint query to the configuration and let the magic begin! 🎇 🪄

1
2
3
4
5
6

      - name: backup
        url: http://n8n-hostname-here/webhook/ca65d99a-10c4-4ce5-be30-4acef4ab63b3
        interval: 24h
        conditions:
          - "[STATUS] == 200"
          - "[BODY].updated == true"