services.restic.backups.my_repo.paths = [ config.services.freshrss.dataDir ];
The point is that you write the general part of the restic config (like the schedule and the S3 endpoint) once, in one place (i.e restic.nix). Then each service-specific part of the restic config, like the line above, lives next to other configs for the freshrss service (i.e. freshrss.nix, not restic.nix). Then a build step generates scripts and systemd units for restic from the merged config. This makes it very easy to remove any service and all traces of it, even when it has “cross-cutting” configs.You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.
This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.
Aside from services, this pattern is everywhere once you start recognizing it. For example, my Claude Code config in Nix adds CLAUDE.local.md to the global gitignore, my Git config adds aliases to my shell, and my terminal config adds a monospace font to the system fonts.
https://github.com/NixOS/nixpkgs/blob/nixos-26.05/nixos/modu...
Given the flake for freshrss doesn't have any sort of explicit "backup" option, my hunch is the author is doing something similar. Point the data dir to a location that gets automatically sync'd elsewhere.
https://github.com/Xophmeister/backer-upper/
I believe there are NixOS options to do this periodically -- which is even easier -- but I specifically wanted on-shutdown backups.