Running a production MySQL instance on a small home‑lab server is a common scenario for many of us. The database is the heart of the service, but it also means that any backup strategy must preserve consistency while keeping the application online. Restic is a popular, fast, deduplicating backup tool that works well with block‑level snapshots and remote backends. In this post I’ll walk through a practical, repeatable method to test incremental Restic backups against a live MySQL server, covering the trade‑offs, commands, and pitfalls you’ll encounter.

Backups are the lifeblood of any homelab or small server. I usually run a nightly rsync job that copies hundreds of gigabytes from a production NFS share to a local Btrfs snapshot. On a 4‑core workstation the job is usually a quiet background task, but sometimes the process spikes to 100 % CPU and the terminal I use to monitor the job freezes. The culprit is often the default scheduling class and priority that rsync inherits from the shell.

Recover a single file from a damaged Borg archive

When a Borg repository gets corrupted, the instinct is to dump the whole thing back. That’s usually overkill if you just need one config file. Borg actually gives you a fine‑grained extraction tool that can pull a single file even from a partially broken archive.

1. Verify the repository

borg check /srv/backups/myrepo

borg check will surface any integrity problems. If you see corruption, you can try to fix it:

Running a nightly backup from a home NAS to a desktop is a common task, but the copy can still hog the machine’s resources and make the UI feel sluggish.
The trick is to let the backup run with low CPU and I/O priority so the desktop stays responsive. Two simple tools—nice and ionice—are all you need.

Why the problem matters

When a rsync or tar job copies gigabytes of data, the kernel’s scheduler keeps the process in the foreground class. Even if you’re not actively using the machine, the backup can consume CPU cycles and saturate the disk queue. On a laptop or a desktop with a single NVMe drive, this shows up as a frozen terminal, delayed window redraws, or a sluggish browser.

The night I lost an off‑site Borg backup

I run a 24/7 home‑lab server that backs up my home directories to a remote NAS with Borg. The backup is triggered by a systemd timer that fires every night at 02:00 UTC. For months it worked flawlessly, but one morning the timer ran, the job logged “ssh: connect to host …: Permission denied”, and the backup vanished into the night. The culprit? A forgotten SSH key.

Running a nightly backup script after logout with systemd user units – no nohup needed

I set up a little home‑lab server last year and wanted a way to snap my home directory every night without tying the job to a terminal. The old nohup trick works, but it leaves orphaned processes and you end up chasing logs in the dark. Systemd user units give a cleaner, more reliable solution that plays nicely with the rest of the system.

Introduction to Rescuing Borked Linux Systems

I’ve seen this go wrong when you least expect it - a misconfigured system file, a failed update, or an accidental deletion of a critical file can leave your Linux system in a borked state. Whether you’re working on a desktop, server, or in a homelab setup, having a reliable method to rescue and restore your system is invaluable. In my experience, rsync combined with temporary snapshots is one of the most effective tools for this purpose.

Introduction to Borg Backup

I’ve been using Borg Backup for years, and it’s been a reliable tool in my homelab setup. However, like any complex system, it’s not perfect, and I recently had to deal with a failed repository. This experience taught me a lot about the recovery process, and I’d like to share my findings with you.

Understanding Borg Backup Repositories

Before we dive into recovery, it’s crucial to understand how Borg Backup repositories work. A repository is essentially a storage location for your backups, and it can be hosted locally or remotely. Borg uses archives to store individual backups within the repository, and each archive contains a snapshot of your data at a particular point in time. I’ve seen this go wrong when the repository becomes inconsistent, so it’s essential to understand the basics.

Introduction to Disk Space Management

I’ve learned the hard way that managing disk space is crucial for a healthy and efficient home server. It’s easy to let disk space consumption get out of hand, especially with the amount of data we generate these days. I’ve seen this go wrong when I didn’t keep a close eye on my server’s disk usage - it was growing at an alarming rate. To get back on track, I’ve implemented a quarterly rsync snapshot and log rotation strategy. The real trick is to find a balance between keeping enough data for backups and not letting logs consume too much disk space.

Introduction to Btrfs Send and Receive

I’ve been working with Btrfs for a while now, and I have to say, its send and receive functionality is one of my favorite features. It makes efficient backups and data replication across systems a breeze. However, like any complex operation, things can go wrong, and you’re left with incomplete or corrupted data. That’s where having a safety net like rsync comes in handy.