dotfiles
Boot and storage

The old Arch archive, mounted permanently

Edit on GitHub

Two modules, one artifact:

  • modules/nixos/services/arch-legacy.nix: the mountpoint and the path's SSOT.
  • modules/home/services/arch-legacy-mount.nix: what actually mounts it.

Why the split

A FUSE mount is private to whoever mounted it, so sudo restic mount produces a folder Dolphin cannot open. That was the defect of the first version. Root only comes in to CREATE the directory, because /mnt is its and the user cannot write there.

The option is declared on the SYSTEM side and not in the home module because of rule 11: the tmpfiles rule is a system module and consumes the path, and a system module cannot read a home-manager option. The home consumers (the unit and the Dolphin bookmark) read it through osConfig.my.archAntigo.*.

The mountpoint is OUTSIDE /home on purpose. Inside /home/v1cferr it would enter the backup's paths and fall into the same trap as ~/Drive and ~/FAI-workstation: root cannot lstat the user's FUSE, restic exits 3, and forget --prune stops running. See docs/notes/restic.md.

Why it moved out of restic.nix (11/08/2026)

The directory used to be created inside restic.nix, alongside /mnt/backup. There it was tied to the restic toggle: turning the backup off would start taking down a mount that is now PERMANENT, and the failure would show up far from the cause (a mount with no mountpoint). /mnt/backup stays there because it remains an on-demand lookup by backup-browse, which is restic's domain.

Why it stopped being an alias

It used to be the arch-browse alias, run by hand and alive only as long as the terminal stayed open. The symptom that killed it (11/08/2026): opening the Dolphin bookmark and seeing an EMPTY folder. There was no defect at all. The secrets were readable, the repo was answering, the mount came up in ~20 s when asked. The defect was the DESIGN: automation with no declared owner (rule 15) that depended on remembering the command and never closing that terminal.

The price of leaving it up (measured 11/08/2026)

~195 MiB of resident RSS: 115 MiB from restic (the repo index in memory, a 44.6 GiB snapshot) plus 79 MiB from rclone serve restic. On the NETWORK, while idle, it is ZERO: restic does not poll, it only reads when somebody reads.

The Dolphin bookmark's comment used to say a permanent mount would be "an open connection and a lock on the repo for nothing". The first half was true and became a conscious choice; the second half is what --no-lock solves.

Why --no-lock, and the premise behind it

Every restic mount creates a non-exclusive lock and renews it every ~5 min; a mount that dies without exiting cleanly leaves it STUCK. On 11/08/2026 the repo had 3 locks: one from the live mount and two leftovers from arch-browse on 05/08 and 08/08. A permanent mount was only going to make that worse, and it would also write to the offsite repo every 5 min forever.

What the lock protects is a read concurrent with a prune. This repo is STATIC: nothing has written to it since 01/08/2026, when the Kingston was formatted, and no routine prunes it (the automatic forget --prune only looks at the HOME repo). If something ever starts writing here, --no-lock is the first line to go.

Readiness, and why it is not Type = "notify"

restic mount does NOT speak sd_notify (checked: no "notify" in 0.18.1's restic mount --help), so there is no copying what ~/Drive does. With Type = simple systemd would call the unit ready the instant the process is born, which is to say BEFORE the mountpoint exists, and Dolphin would open the empty folder and cache that: exactly the symptom this module came to solve.

So ExecStartPost blocks "started" until the mount actually shows up: 120 attempts of 1 s. A cold cache (the index not yet downloaded from the Drive) took ~20 s when the repo was still there, and off the local disk it is far quicker; the slack is for a bad network, and the ceiling exists so Restart=on-failure can try again instead of leaving the unit "activating" forever. TimeoutStartSec = 180 because 120 s of waiting plus restic's startup do not fit in the default 90 s, and blowing past it KILLS the unit mid-wait.

It is a writeShellApplication and not a loose .sh nor a two-line sh -c (rule 7): the logic lives in the build, and that way it goes through shellcheck.

Why the repo left the Drive (24/09/2026)

It used to live at rclone:gdrive:BACKUPS_EX-B560M-V5/ARCH-KINGSTON and came down to /mnt/seagate-old/restic-arch-kingston. The trigger was the Google account blowing past its 15 GiB quota: 130 GiB in use, of which 78.75 were the two restic repos and 30.62 were packs that forget --prune had deleted straight into the Drive's TRASH, where they went on counting against the quota. The whole measurement is in restic.

This archive is 23.67 GiB holding a 44.6 GiB snapshot, and it has NO source to regenerate it, so deleting was never on the table. Local it costs no quota, and it is the better fit anyway: the repo is STATIC and read on demand, which is what belongs on a cold disk.

Three things left the unit along with the Drive, because none of them has a local equivalent: the writable copy of rclone.conf, RCLONE_CONFIG in the environment, and -o rclone.program=<store path>. So did the network-online.target ordering. What the unit needed after that was the Seagate's system mount, until the repo moved to the NVMe on 03/10/2026.

What replaced "if the network drops"

The old failure mode was rclone timing out and the mount going zombie ("Transport endpoint is not connected"), fixed with systemctl --user restart arch-antigo-mount. That one is gone with the network.

On the NVMe, with a second copy (03/10/2026)

The Seagate was reformatted to hold the backup (decision 0011), so the repo moved to ~/Archive/restic-arch-kingston first. The copy was PROVEN before the format, not assumed: restic check --read-data read and hashed every pack, "no errors were found".

Its second copy is inside the backup repo, put there with restic copy and tagged archive, which the prune keeps regardless of age. The folder itself is in my.backup.exclude, since backing up encrypted packs a second time would only store them twice. That ends the "one copy on a dying disk" debt this note used to carry.