Backing up your data

This guide is about the only backup that really saves you: the one that leaves the NAS.

Everything else LGM-OS does for your data lives inside the same machine. RAID survives a disk breaking, not the machine breaking. Snapshots undo a deletion, not a fire, a theft, a power surge that takes the disks with it or ransomware that encrypts whatever the NAS has mounted. The configuration backup (nas-config-*.tar.gz) puts the panel back the way it was, and not a single file of yours.

1. The 3-2-1 rule applied to this NAS

3 copies of every piece of data · on 2 different media · with 1 off the premises.

On a home NAS that translates into something very concrete:

Snapshots do not count as a backup: they share the disks with the original. They count as history, which is just as useful but for a different problem.

If you can, raise it to 3-2-1-1-0: one of the copies disconnected (a USB disk kept in a drawer or away from home and only plugged in to copy — the only thing ransomware cannot reach) and 0 errors, that is, test restores that get done and written down (section 6).

2. What to copy

Not everything deserves to leave the NAS: the off-site copy is usually the most expensive and slowest resource you have. Sort it by what would happen if it disappeared.

Two details everybody forgets:

• Include the NAS configuration. Download a nas-config-*.tar.gz (Control Panel → Configuration backup) into a folder that goes into the off-site copy, or schedule the configuration task towards that folder. Without it, recovering the machine means rebuilding users, permissions and shares by hand.
• Stop writing before copying an app's data. A database copied while it is running can restore corrupted. Stop the container (or use its own scheduled dump) and copy afterwards. For ordinary files there is no need.

And mind the network recycle bin: it lives inside the shared folder itself, so it gets copied with it. Schedule an "Empty old recycle bin" task (Control Panel → Scheduled tasks) so that what you deleted months ago does not keep travelling to your off-site copy.

3. Where to copy to

The app handles three kinds of destination: local (a path on the NAS, typically a mounted USB disk), remote over SSH (rsync against another server) and cloud (Google Drive, OneDrive, Dropbox, Box, pCloud, MEGA, WebDAV, Amazon S3, Wasabi, MinIO and Backblaze B2).

One pattern that works very well and costs nothing: reciprocal backups. Your NAS copies to your brother's house and his copies to yours. Each of you provides a disk and electricity, nobody pays a subscription, and both copies are miles apart.

Cloud backups

Backups → Destinations → New destination → Cloud. There are two ways to connect, depending on the provider:

• With your account (Google Drive, OneDrive, Dropbox, Box, pCloud). The panel gives you a link, you sign in with your account on the provider's website and paste back the address it redirects you to. The NAS stores the permission, not your password.
• With keys (S3, Wasabi, MinIO, Backblaze B2, WebDAV, MEGA). You paste the access key and the secret the service gives you. On S3 and B2, the bucket name is the first part of the destination folder: mybucket/LGM-OS.

How versions are kept. On a disk or over SSH, each copy reuses the files that did not change through hard links, so a daily version only takes up what changed. In the cloud there are no hard links, so it works differently: actual/ is a mirror of your folders and, every time a file is replaced or deleted, the previous version is moved aside into a folder named with the date of the previous copy. Nothing is lost, but an old version contains only the files that changed afterwards, not the complete picture of that day.

End-to-end encryption (optional, and recommended). When creating the destination you can turn encryption on: names and contents are encrypted on the NAS before anything is uploaded and the provider only sees unreadable data — neither your photos nor their names. The key is generated by the NAS and shown to you once as a recovery phrase: write it down outside the NAS (paper, a password manager). The NAS keeps it so it can copy every night, but if the NAS dies, that phrase is the only thing that opens the backup; with it and any rclone you can recover from any machine. It is decided when creating the destination and cannot be changed afterwards: encrypting a destination that already has copies would split the mirror into two halves that cannot read each other. The explorer and restoring work the same with encryption as without it.

Before you start: look at how much your folders take up. Uploading 2 TB over a home fibre line with 300 Mb of upload is about fifteen days at full speed. The sensible thing is to start by copying only what is irreplaceable (documents, photos) and leave out whatever can be downloaded again.

What it does NOT do yet (and why that is said here)

• Encryption for disk or SSH destinations. There, each version is built with hard links against the previous one, and per-file encryption changes the contents on every pass: it would break exactly what makes versions cheap and restoring a single file possible. In the cloud it does exist (see above), because there are no hard links to lose there. If the disk or the server are not yours, encrypt the disk at the other end (LUKS).
• A system disk image (bare metal). After a disaster you reinstall from the ISO and restore the configuration; it is quick, but it is not "clone and boot". It is covered in disaster-recovery.md.

About the destination's privacy: the transport is encrypted when you copy over SSH, but the files that arrive are readable by whoever administers that machine. If the destination is not yours, encrypt the destination disk (LUKS at the other end, or the USB disk itself) and keep that password outside the NAS (a password manager, paper in a drawer).

4. How often

The useful question is not "how often do I copy" but how much work am I willing to lose. That is your frequency.

Schedule the backups outside your usage hours and not all at once: an off-site copy at the same time as a scrub leaves the NAS slow for hours. A good split is a copy at 03:00 and a scrub one Sunday a month at 05:00.

And something nobody does until it happens to them: turn the alerts on (Control Panel → Alerts, SMTP or webhook). A backup task that has been failing silently for three months is exactly as useful as having no backup. The app's status tab also warns you when there is no backup configured, when the last one failed, when a task has gone too long without running, when it is disabled or when its destination is unavailable.

5. Setting up a backup step by step

The Backups app separates two things, and it is worth understanding why:

• Destinations — where it is stored: the USB disk or the remote server. You define them once and test them with the "Test connection" button, which does not only say whether it works: it shows step by step which check fails (the folder, the permissions, the key, the rsync at the other end) and which command to run to fix it. Test them before trusting them, and again when you change something: a USB disk unplugged or a server switched off is better discovered there than at three in the morning.
• Tasks — what is copied and when: source folders (with optional exclusions), destination, schedule and how much is kept — the smart retention out of the box, or by number of versions or by age in days.

Every run leaves a restorable version at the destination and an entry in the history (with date, size and the exact error if it failed). With Explore you go into any version as if it were a folder —which files were there that day, with their size and date— and restore the whole version or only what you tick, down to a single file.

5.1 To a USB disk or another pool (local destination)

1. Plug the disk in. If it comes from Windows, format it from Storage (ext4/Btrfs) or leave it as NTFS/exFAT: LGM-OS mounts it either way, but **NTFS and exFAT do not store Linux permissions or owners**, so whatever you restore will arrive without them. For serious backups use a Linux-formatted disk.
2. Create a local destination with the path where the disk is mounted, and test it: the test really writes into that folder, which is the only way to know that it can.
3. Create the task: name, source folders, that destination, schedule and versions to keep.
4. Run it by hand once and watch it finish. Check the size at the destination afterwards: if it is 4 GB for a 400 GB folder, review which folders you chose as sources.

5.2 To another server over SSH (remote destination)

This is where 90 % of the questions are, so here it is in full detail. We will call NAS your machine and remote server the one receiving the copy.

Step 1 — Get the NAS's public key

In the Backups app, when creating a remote destination, the NAS generates its own SSH key pair and shows you the public one. It is a single line, something like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

The private one stays on the NAS, in /etc/nas/ssh, a directory only root can read: neither the panel nor any API route can show it, because the process serving the web runs unprivileged. Copy it exactly, whole and on a single line: if it breaks in two when pasted, the authorisation will not work.

Step 2 — Create the user that will receive the copy (on the remote server)

Do not use root or your personal account. A dedicated user with no login password:

sudo adduser --disabled-password --gecos "" backups
sudo install -d -m 750 -o backups -g backups /backups/nas    # destination folder

Step 3 — Authorise the key (on the remote server)

The app gives you this same command already built with your key, ready to copy and paste into an SSH session on the remote server opened with the user that will receive the copy:

mkdir -p ~/.ssh && chmod 700 ~/.ssh \
  && echo 'ssh-ed25519 AAAA…' >> ~/.ssh/authorized_keys \
  && chmod 600 ~/.ssh/authorized_keys

If you would rather do it from another account with sudo, the equivalent is:

sudo install -d -m 700 -o backups -g backups /home/backups/.ssh
sudo -u backups tee -a /home/backups/.ssh/authorized_keys >/dev/null
# paste the full public key line here, press Enter and then Ctrl+D
sudo chmod 600 /home/backups/.ssh/authorized_keys

The permissions are not cosmetic: if .ssh is not 700 or authorized_keys is not 600, OpenSSH ignores the key without explaining why and you get a baffling "Permission denied (publickey)".

Recommended — limit what that key can do by adding options at the start of the same line, before ssh-ed25519:

restrict,from="203.0.113.10" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB4o…9c2K nas@lgm-os

• restrict disables port forwarding, agent forwarding, X11 and an interactive shell. rsync still works (it needs OpenSSH 7.2 or later; Debian 11 and 12 are well past that).
• from="…" accepts that key only from your public IP. If your IP is dynamic, it accepts your DDNS name (from="myhouse.duckdns.org") or you can drop the option.

Advanced level, if the remote server is not entirely yours: rrsync locks the key into a single directory in write-only mode, so it cannot even read the rest of the disk. On Debian 12 it comes with the rsync package at /usr/bin/rrsync (on earlier versions, compressed in /usr/share/doc/rsync/scripts/):

command="/usr/bin/rrsync -wo /backups/nas",restrict ssh-ed25519 AAAA…

Bear in mind that with -wo (write only) the copy goes in but you cannot restore over that same route: restoring is done from the remote server or by lifting that restriction temporarily. It is a conscious trade-off, not an oversight.

Step 4 — Check the remote server's fingerprint

The first connection will ask you to accept the server's fingerprint. Accepting it blindly means accepting any machine that puts itself in the middle, so get the real one by running on the remote server:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare that SHA256:… string with the one the NAS shows when testing the destination. They match or you do not accept it.

Step 5 — Test the connection and save

Use the destination's test button in the app: it checks that the NAS gets in, that the folder exists and that it can write to it. If you prefer to see it from the NAS console, do it as `root` and pointing at the managed key, which is the one the backups will use (the privileged process is the one that runs rsync, not the service user):

sudo ssh -i /etc/nas/ssh/id_ed25519 -p 22 backups@server.example.com 'touch /backups/nas/.test && echo ok'

What each typical failure means:

Step 6 — Create the backup task

Name, source folders, that remote destination, schedule and how much is kept. If the destination machine is not yours, encrypt the disk that receives the copy there (LUKS): the panel does not encrypt at the source yet, and it says so. First run by hand: the initial copy sends everything and can take hours or days depending on your upload line. The following ones are incremental (rsync only sends what changed) and take minutes. If the first copy over the internet is unfeasible, do it locally: take the NAS or a USB disk to the remote server's location, copy over the local network and then change the destination to the remote connection — rsync will see that almost everything is already there and will only send the differences.

5.3 Retention: a backup is not a mirror

One detail that decides whether you survive ransomware or not. If the copy just mirrors the source, a file deleted (or encrypted) on the NAS today gets deleted (or encrypted) in the copy tonight.

Defences, weakest first:

1. Versions kept in the task: every run leaves a version and only the oldest are deleted once you go past the number you set. With 7 daily versions you have a week to notice that something broke; with 1 version, none. Count the space: N versions take up more than one, even though the parts that do not change are shared between them. The smart retention (the default) does this without numbers: it keeps every copy from the last 24 hours, one a day for 7 days, one a week for 4 weeks and one a month for 12 months — plenty of recent ones for today's scare, and a year of depth for what gets noticed late. It counts "the last N periods **with copies**", like restic: if the NAS spent months switched off, what came before the gap is not thrown away just for being old.
2. Snapshots at the destination: if the remote server is another NAS with ZFS or Btrfs, have it take its own snapshots of the backup directory. It is the cheapest and most effective protection there is.
3. A disconnected copy: the USB disk in the drawer. Nothing that is not plugged in can be encrypted.

6. Proving the backup works (the one part that is not optional)

An unverified backup is not a backup: it is a big folder you trust on faith. The three indicators that prove nothing are the task showing green, the size at the destination and "rsync gave no error".

Each task's Check button does half the work without moving a byte: it reads the whole copy at the destination and checks that it matches what was recorded when copying (on disk and over SSH, the file count and the size of the version; in the cloud, the comparison between what the mirror weighs and what the source weighs). The result stays on the card and in the history, and if it does not match the NAS warns you as it warns about a failed backup. It catches the copy that stopped halfway, the destination that lost files and the disk that is dying — what it cannot prove is that the bytes inside each file are still the right ones, so the check complements the real test, it does not replace it.

The only valid proof is really restoring and opening the restored file. With the explorer it has never been cheaper: go into a version, tick three files at random and restore them to a temporary folder.

And if the destination disk is encrypted (LUKS), the test includes opening it with its password: an encrypted disk whose key nobody remembers is occupied space, not a backup.

Test plan

Test restore (monthly)

From the app: pick the task, the version you want to recover and a new destination folder — never on top of the original, because if something goes wrong you will want to compare the two. The restore runs as a task, with its progress, just like the copy.

Then open a few files: a photo that displays, a PDF that opens, a video that plays. A 4 MB file that exists but does not open is a lost file. And delete the test folder afterwards, it takes up as much as what you restored.

Full restore of a folder (quarterly)

From the app, restore a whole folder to /mnt/<pool>/restore-test and compare it with the original. From the NAS console:

# 1. Compare with the original: it should list no differences
sudo diff -qr /mnt/tank/documents /mnt/tank/restore-test

# 2. Strong verification (compares contents, not dates or sizes)
sudo rsync -avnc --delete /mnt/tank/documents/ /mnt/tank/restore-test/

# 3. Delete the test folder when you are done
sudo rm -rf /mnt/tank/restore-test

In step 2, -c compares checksums (slow but honest) and -n changes nothing: if that command lists no files, the contents are identical bit for bit. Mind the space: the test temporarily doubles whatever you restore, so pick a folder that fits.

One important nuance if you restore an old version: differences from today's original are normal (that is what changed since then). For this comparison use the latest version, or compare only files you know you have not touched.

Write down the result

Two lines per test, wherever you like, but write them down:

2026-07-25 · Restored 4 files from the remote copy · they open fine · 3 min
2026-07-25 · Full restore of "documents" (38 GB) · diff shows no differences · 41 min

The figure almost nobody measures is the restore time. Knowing that recovering 2 TB over the internet is four days changes decisions: you may want the local copy as well as the remote one, or a disk you can go and fetch by car.

What to do if the test fails

The test fails, not the day of the disaster: that is exactly what it is for. Review the task's sources (was a folder missing?), the destination's permissions, the history in case it had been failing silently for weeks and, if the destination disk is encrypted, that the password is the one you think it is. Fix it, copy again and test again.

7. What this backup does not cover

Honestly, so it does not catch you by surprise:

• A corrupt file that gets copied corrupt. rsync copies what is there. Against that you have ZFS/Btrfs checksums and scheduled scrubs, which catch corruption at the source before it spreads.
• Whatever you did not pick as a source. A new shared folder does not join any task on its own: when you create one, add it to the task it belongs to or it will stay out of the backup with nobody warning you.
• Upload time. A home line with 300 Mbps down usually has 30 up: about 10 GB an hour at best. Size the first copy with that in mind.
• Passwords and 2FA. The configuration backup does not carry the session signing key (it is regenerated) and your TOTP codes are on your phone, not on the NAS. Keep the recovery codes somewhere else.

8. The cloud backup fails

First things first: the error message in the Backups app now says what the cloud answered (out of space, expired permission, wrong address…). That text is the diagnosis; what follows is for the cases that keep coming up.

Nextcloud and other WebDAV: use an app password, not your account's (Settings → Security → Devices and sessions). If the server sits behind a proxy with an upload size limit, that limit overrides any NAS setting.

See also

• Disaster recovery — what to do once it has happened.
• Administration guide — snapshots, scrubs, alerts.