Over‑Engineering a Homelab: Logging, Backup and Business Continuity with Ubuntu Server

This article stems from a very real problem: knowing if your backups are actually working, without having to manually check scattered logs, opaque cron scripts, and unreliable notifications.

In my homelab (which still remains a house, not an enterprise data center) I decided to apply Business Continuity and Disaster Recovery principles typical of professional environments:

  • deterministic and verifiable logging
  • clear separation between execution And check
  • principle of fail-closed (Better one more alert than a lost backup)
  • external and immutable audit trail

The result is an architecture that revolves around Ubuntu Server, redundant backups (Oracle Cloud + Hetzner), Google Cloud for logging and a workflow n8n which validates every day that everything went well.

This article explains the architecture, the technical choices and the Why. The n8n workflow is a paid product: I describe it transparently, but without releasing sensitive or one-to-one replicable information.

The real problem (first)

Before this architecture, the flow was the classic:

  • cron job → rsync / rclone
  • local logs
  • manual control “when it happens”
  • alert only in case of obvious errors

This approach has three structural flaws:

  1. Silence ≠ success
    If a job doesn't get off the ground or dies halfway, you often don't find out right away.
  2. Local logs = single point of failure
    If you lose the VM, you also lose proof that the backup was made. era match.
  3. Wasted human time
    Reading raw logs is expensive and error-prone.

Hence the decision to consciously over-engineer.

Project objectives

The goals were not to “do cool things”, but to be operationally calm:

  • know everyday if all jobs have run
  • know which job he failed and Why
  • have logs immutable off the server
  • be able to demonstrate after the fact what happened (audit)
  • zero reverse dependencies: control must never touch the server

High-level architecture

Ubuntu Server (on‑prem / Proxmox) ├─ cron ├─ rsync / rclone ├─ structured logs │ ├─ Google Cloud Logging (streaming) └─ Google Cloud Storage (snapshot log) │ ▼ n8n (monitoring & validation) │ ├─ check log presence ├─ deterministic parsing ├─ content analysis └─ alert / ticket

Key separation:

  • Ubuntu Server runs
  • n8n observes

No SSH, no API to the server. Zero trust in the data producer.

Ubuntu Server as a foundation

Ubuntu Server is the starting point:

  • VM on Proxmox
  • local storage + dedicated disks
  • versioned scripts (Git)
  • cron simple, but observable

Structured logs, not “random text”

Each backup job produces logs with:

  • marker of START, RSYNC_END, SUMMARY, END
  • run_id unique
  • rc, duration, warnings, errors

This allows:

  • deterministic parsing
  • detect incomplete runs
  • distinguish warning from failure

It's not logging "for humans", it's logging for the machines.

Redundant backups ≠ Business Continuity

Making multiple copies is not enough.

There Business Continuity requires:

  • know that all copies have been updated
  • know When a copy is not
  • react proportionately

Because of this:

  • Oracle Cloud and Hetzner are just target
  • the truth is in the logs
  • continuity is in the automatic verification

External logging: Google Cloud

Logging is divided into two complementary channels.

1. Google Cloud Logging (streaming)

  • near-real-time ingestion of rsync logs
  • quick queries
  • immediate troubleshooting
  • very low costs (often zero)

It is used for:

  • analyses
  • debug
  • operational visibility

2. Google Cloud Storage (immutable snapshots)

  • daily log upload
  • deterministic path YYYY/MM/DD
  • versioning and retention
  • service account with minimal permissions

It is used for:

  • audit
  • independent verification
  • n8n workflow input

This bucket is the source of truth for monitoring.

The role of n8n (monitoring, not backup)

The n8n workflow does not perform backups.

It only does three things, in order:

  1. Check attendance
    Do all the logs expected for today exist?
  2. Check integrity
    Does each log have a consistent START/END/SUMMARY?
  3. Semantic verification
    Errors? Warnings? Abnormal patterns?

If something is missing or not correct → alert.

Why n8n?

  • readable workflows
  • versionable
  • extendable
  • decoupled from the server

The value is not “automation”, but the validation.

Where to buy it

Because it's a paid workflow

This workflow:

  • encapsulates months of real-world debugging
  • handles edge cases (incomplete logs, duplicates, partial runs)
  • it is meant to be extended, not only used

He doesn't sell magic.
Sells time saved And mistakes avoided.

Where to buy it

  • shop.paoloronco.it
  • Gumroad
  • n8n Creators Hub (template)

The sensitive code remains mine.
The architecture and principles are shared.

Safety and key principles

  • Single-purpose Service Account
  • minimum permits
  • no credentials in the workflow
  • no direct access to the server

If n8n were to be compromised:

  • can only read public logs for him
  • cannot touch backups or servers

This is zero trust applied to a homelab.

What did this architecture take away from me?

  • daily manual check
  • anxiety about “has he left?”
  • night debugging
  • useless logs

In exchange I got:

  • measurable trust
  • significant alerts
  • audit trail
  • operational serenity

Conclusion

This project was not born to demonstrate that it can be done.

It was born because I didn't want to waste time doubting backups anymore.

Even in a homelab, data matters.
And when data matters, Logging is part of backup, not a detail.

Over-engineering? Perhaps.
But it is over-engineering that sleeps peacefully.

Leave a Reply

Your email address will not be published. Required fields are marked *