Backing up your data

32 min · 11 sections

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.

2 ante. My folder everywhere (the NAS's own "Drive")

First of all, the sentence worth reading twice: this is not a backup.

A synced folder is a live mirror: what you save on the laptop appears on the NAS and on the rest of your machines, and what you delete on one disappears from all of them. It is exactly what you want in order to work — the file is wherever you are — and exactly what you do not want for protection: a deletion, ransomware or a "save over it" travel just as fast as a new file. What protects you from that are the NAS snapshots, which run on their own, take almost no space, and which ransomware on the laptop cannot reach.

You set it up in Backups → Sync, at the top.

How it is built

Over WebDAV, which the NAS already serves: tick "WebDAV" on the shared folder, pick it here, and it is published. On the computer it uses rclone, which exists for Windows, Mac and Linux and is the same program this NAS uses for everything else. The panel gives you the configuration ready-made, with the NAS name, the folder and the interval already filled in.

There is no proprietary program to install on each machine, and that is deliberate: a desktop client for three systems is three installers, three signatures and three update channels to maintain forever, and every one of them is a new way for the NAS in your house to end up unsupported.

The password never leaves the NAS. The text you copy has a blank you fill in on the computer itself. A text that gets copied and pasted ends up in the clipboard, in a chat and in a screenshot.

Conflicts: nothing is ever thrown away

Two computers touch the same file without seeing each other — one on a plane, one at home. There are two policies and neither of them deletes:

Choosing for you and throwing away somebody's work is not an option. When a conflict appears, the NAS warns you saying where the other version is: without that sentence, people look in the recycle bin and write off what is sitting right next to it.

And what a hand-rolled rclone bisync cannot give: knowing it still works

Every computer sends a report at the end of each pass, and the panel shows a traffic light per machine. If one goes quiet, the NAS warns you. Same reason as with home computers: a folder that stopped syncing in March looks exactly like one that synced five minutes ago — the files are still there — and the difference only shows on the day you go looking for what you thought you had saved.

The threshold is twelve times that machine's interval: with five minutes, one hour. A laptop closed for a while is not a broken laptop.

Details that cost you if you do not know them

• The first pass is different. It carries --resync and pairs the two sides; after that it is never used again. Putting it in every pass turns the mirror into "whatever one of the two sides says", which is the command that deletes the other one's work.
• It syncs as the NAS user, with their permissions: if that person cannot write in the folder, neither can the sync.
• Stopping the sync deletes nothing. Removing the folder from the list cuts the mirror; the files stay on the NAS and on the computers.

2 bis. Home computers: backing up the laptop and the PC TO the NAS

Everything above is about getting out of the NAS what is already inside it. This is the other way round: the home laptop and PC leaving their backup on the NAS. And there is a reason to treat it separately: a laptop disk is the most easily lost thing in the house — it gets dropped, soaked, stolen — and it is what almost nobody backs up.

Backups → Computers has a wizard that sets it up in one step: it creates a shared folder just for that user, gives it a space cap, turns on Time Machine if it is a Mac, and tells you exactly what to click on that computer. No protocol is invented: Time Machine and Windows File History already know how to back up to a network folder.

What really matters: finding out it has stopped

Both systems already knew how to back up. What nobody did was notice that one of them stopped, and that is where data is actually lost:

• Time Machine gives up silently after failing to find the disk a few times in a row.
• Windows File History switches itself off when the network changes.
• The quota fills up and the backup stops writing.

None of the three makes any noise. A backup stopped in March and discovered in December is nine months of photos. That is why every registered computer has a traffic light — up to date, behind, NOT BACKING UP — and the NAS warns you when one goes quiet. The interval is set per computer ("expected every N days") and the alert does not fire until three times that interval: a laptop switched off for the weekend is not a broken laptop, and a system that shouts about that teaches you to ignore it.

To know when it last backed up, the NAS looks at the date of the newest thing in that computer's folder. Nothing needs to be installed: Time Machine and File History do not report to anybody, so either you look at the folder or you do not know.

The script, if you want to choose the folders yourself

For Linux, or for anyone who wants something finer than Time Machine, the panel provides a script — four lines of PowerShell or shell, with the NAS name and folder already filled in — that copies what you tell it and reports back to the NAS. With the script the traffic light stops being a guess and becomes a report: if robocopy or rsync fail, the alert arrives that same night instead of three intervals later.

It copies with what the system already ships — robocopy on Windows, rsync on Mac and Linux — and not with a program that has to be installed and maintained on every laptop in the house. And versions are not made by the script: it leaves a mirror, and the versions are the NAS snapshots, which already run by themselves, take almost no space, and ransomware on the PC cannot reach.

The script carries a token for that computer. It only serves to say "I have backed up" — it grants access to nothing — and it is discarded by removing the computer from the list.

What this does NOT do

It does not clone a PC's whole disk nor let you boot from the backup (bare metal). Files are copied, not systems. If a laptop breaks you get your documents and photos back, but Windows or macOS have to be reinstalled.

And removing a computer from the list does not delete its folder or what it already copied: it just stops being watched. Deleting somebody's data as a side effect of removing them from a list is the kind of surprise a backup system must never spring.

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.

Shielding the destination (so the NAS cannot delete its own backups)

The SSH key and the cloud token live inside the NAS, which is precisely the machine assumed to be compromised when ransomware arrives. Serious ransomware does not start with your photos: it starts with the backups, and deletes them with your own credentials before asking for the ransom.

Every destination has a Shield this destination switch, and what it does depends on the type:

And the important part: it is tested, not promised. The Test the lock button leaves a decoy file at the destination and tries to delete it. The deletion failing is the good outcome. It is the only way to know: a lock_days saved in the configuration does not prove the bucket has Object Lock, and a "restricted" key nobody has tested usually is not. The NAS repeats that test once a week and warns only when a destination that was shielded stops being shielded — somebody reinstalled the server and put the key back unrestricted, the bucket was recreated without Object Lock…

For an SSH destination the panel gives you the exact line to paste into the backup user's ~/.ssh/authorized_keys at the other end. Writing it by hand is where people get it wrong.

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 a folder of the NAS itself or for 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 and on a USB disk it does exist (see above and 5.1), because there the backup is a mirror and there are no hard links to lose. If the remote server is 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 task also has a maximum speed in MB/s, on the last step of the wizard. Leave it empty and the backup goes as fast as it can; set a number and it will not go above it. That is what you want when the backup goes to another machine or to the cloud and you do not want it eating up your home upload: with 100 Mb/s of upload (about 12 MB/s), a 6 MB/s cap leaves half of it free for everything else. It only slows backups down: restores are never throttled, because there is always someone waiting for those.

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.

If that disk leaves the house, encrypt it. When the destination folder is on a USB disk, creating it shows "Encrypt what is kept on this disk". With the switch on, names and contents are encrypted on the NAS before anything is written: a lost or stolen disk cannot be read. The disk keeps its usual format —exFAT, NTFS, ext4— and, with the recovery phrase, it opens on any computer that has rclone, even if the NAS is gone. The phrase is shown just once, when you create the destination: write it down away from the NAS and away from the disk, because without it nothing can be recovered. It is decided at creation time and cannot be changed afterwards. In exchange, that destination keeps versions the way the cloud does (an actual/ mirror plus, dated with each pass, whatever was replaced) instead of using hard links.

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.

The automatic drill (the NAS does it by itself)

Everything above is right and almost nobody does it. So the NAS does it for you: once a month it takes a few random files from each task's latest backup, really restores them to a temporary folder and compares them against the original. Then it deletes what it restored and reports it in the weekly report.

This is not the Check button — that one looks at sizes and file counts. The drill restores, with the same programs and the same path you would use on the bad day, and compares byte by byte against the original: it is the only thing that catches a destination that accepts writes and returns garbage, a lost encryption key, or a disk that reads badly exactly where your photos were.

How it avoids being a nuisance, and how it avoids lying:

• Twenty files, half a gigabyte and fifteen minutes at most. On a two-terabyte backup it goes unnoticed; and being random, in a year it has tested half the backup.
• It only picks files that already existed when the backup was made. If you touched the original afterwards, the copy has to differ, and comparing them would manufacture a failure. With that rule, "different" can only mean "the backup is wrong".
• It touches nothing. It restores to a temporary folder and deletes it when done.
• What could not be compared is not counted as good. It is counted separately: the number shown as verified is the number that was actually compared.

You can see it in Backups → Tasks, below the list, with a Test now button in case you do not want to wait a month. It also gets its own section in the weekly report; if a backup does not come back you get an alert and the report score drops sharply: a backup that exists and does not come back is worse than no backup, because nobody is looking for another one.

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.