Configure scoped Restic backups from sietch and jacurutu to dar-es-balat

[Kabilan108]

Goal

Configure encrypted, unattended machine backups from sietch and jacurutu to their dedicated shares on the Synology NAS dar-es-balat, without exposing NAS credentials or mounts to ordinary user/agent sessions.

This work was intentionally split from the initial NAS setup rollout so backup scope, live-service consistency, retention, and restore behavior can be designed and verified independently.

Completed DSM prerequisites

• SMB is enabled with minimum SMB2 with Large MTU and maximum SMB3.
• Encrypted Btrfs volume and immutable snapshot schedules are active.
• Shared folders exist:
  • backup-sietch
  • backup-jacurutu
• Non-administrative service accounts exist:
  • svc-backup-sietch: SMB allowed; read/write only to backup-sietch; no access to all other shares; interactive DSM/File Station/Photos/etc. denied.
  • svc-backup-jacurutu: SMB allowed; read/write only to backup-jacurutu; no access to all other shares; interactive DSM/File Station/Photos/etc. denied.
• Credentials are stored in Vaultwarden and have not been placed in chat or the repository.
• sietch wired IP is reserved as 10.0.0.71; NAS LAN IP is reserved as 10.0.0.240.

Proposed design

• Use a root-only CIFS/SMB3 mount on each client.
• Use a Restic repository inside each machine's dedicated share.
• Give each repository its own Restic encryption password, distinct from its SMB password.
• Store SMB credential files and Restic passwords as machine-specific agenix secrets, owned by root with mode 0400.
• Run mounts and backups from root-owned systemd units. Do not expose credentials or backup mounts to kabilan, agent sessions, containers, or other services.
• Use SMB3 transport encryption (seal) and test compatibility/throughput before changing DSM from client-defined encryption to forced encryption.
• sietch uses the wired LAN endpoint 10.0.0.240.
• jacurutu initially uses the tailnet path; migrate it to its future reserved dock IP after wired docking is available.
• Keep immutable NAS snapshots as protection against a compromised source deleting or corrupting the live Restic repository.

Required design decision: backup scope

Default recommendation: personal data only. Do not copy employer/Moberg data onto personal infrastructure without an explicit decision.

Audit both machines before finalizing paths and exclusions. Likely exclusions include:

• /vault/work/moberg*
• /vault/moberg-data
• VMs and ISO images unless explicitly requested
• caches, build outputs, dependency trees, and reproducible downloads
• Google Takeout staging archives already handled by the separate Photos import rollout
• NAS/CIFS mountpoints to prevent recursive backup

Candidate personal data includes notes, personal repositories, userdata, Zotero data, dotfiles/local configuration, and selected self-hosted service state.

Live application state must be captured consistently. In particular, do not blindly copy a running Vaultwarden SQLite database; use an application-aware SQLite backup/export or a verified quiesced snapshot and include its attachments/configuration as appropriate.

Implementation tasks

• Confirm personal-only versus work-data scope.
• Inventory candidate source paths and sizes on both machines without crossing the fleet's directional SSH policy (sietch must never SSH into jacurutu).
• Design a reusable NixOS module for the root-only CIFS mount and Restic job.
• Add machine-specific agenix recipient declarations in secrets.nix.
• Have the user enter each SMB password and Restic password interactively; never expose plaintext in chat, shell history, tool output, or the git worktree.
• Configure hardened root-only CIFS mounts (vers=3.1.1, transport encryption, nodev, nosuid, noexec, restrictive file/directory modes, automount or explicit unit dependency).
• Configure Restic initialization, nightly backups, retention/pruning, and periodic integrity checks.
• Add safe exclusions for caches, mounts, temporary data, build products, and organizational data outside the approved scope.
• Add consistent backup hooks/exports for stateful services, including Vaultwarden.
• Integrate success/failure notification using the existing fleet notification mechanism without including secrets or sensitive filenames.
• Run nix flake check --no-build and other non-destructive validation.
• User rebuilds each machine; agents must not run the rebuild.
• Verify each service account cannot access the other backup share or any general NAS share.
• Verify SMB dialect, encryption, mount ownership, and lack of access from an ordinary user/agent session.
• Complete an initial backup on each machine.
• Restore representative files into a temporary directory and compare hashes/metadata.
• Test Restic repository integrity and retention behavior.
• After both clients pass, consider forcing SMB3 transport encryption in DSM.
• Update docs/nas-network-policy.md and the NAS implementation log with the verified final state.

Acceptance criteria

• Each machine can write only to its own backup share using its own scoped account.
• SMB and Restic secrets exist only as encrypted repo files and root-only runtime material.
• Ordinary user and agent sessions cannot read the credentials or browse the mounted repository.
• Backups run unattended and report failures.
• The backup scope excludes unapproved employer data and recursive/reproducible bulk data.
• At least one real restore from each repository is hash-verified.
• Deleting/corrupting live repository content from a simulated client does not remove the immutable NAS snapshot recovery points.

Out of scope

• Google Photos Takeout processing/import.
• Jellyfin's read-only NFS migration.
• Encrypted off-NAS replication (separate but still required for disaster recovery).
• Adding the second SHR disk.
• VLAN/IoT redesign.

References

• docs/nas-network-policy.md
• https://page-bin.com/p/hR7O1i7HPptx1Gopa4e4sw/B2orWq8dUF6bmRwQfDukzHhd0rsow3adCuyiRkctEYo
• docs/handoffs/2026-08-04-google-photos-takeout-import-handoff.md