I don't know exactly how Repology works, but I was interested as well.
This holds what sources are being used for repology in Debian: https://github.com/repology/repology-updater/blob/master/repos.d/deb/debian.yaml This repository seems to be used to merge/split package names: https://github.com/repology/repology-rules
The packages of Debian are split into different subpackages (dev, lib, doc and its base). This happens for Nix as well, but packages there just have different outputs. For instance, openssl has as outputs: bin debug dev doc man out. I don't think repology counts those outputs, so it shouldn't count subpackages as well. I guess these rules are merging these together: https://github.com/repology/repology-rules/blob/master/800.renames-and-merges/openssl.yaml.
I also had been contenplating this for a while. The solution I implemented recently is:
The system itself is a RPI on NixOS. The system can be reproduced from the NixOS configuration. The NixOS configuration is stored on GitHub. Since I can reproduce the sdcard image (and full system) from the configuration I opted to not do any backup of the sdcard/system itself.
I've also opted to not use raid, as I can replace/add a RPI without too much hassle.
The real backups for me are for photos. Those are stored on a M.2 storage. A second (similar) RPI is placed at my dad's place. The rpis run tailscale and syncthing. Syncthing syncs using staggered mode (stores 1 version for the last day/week/year) and the RPI at my dad is untrusted, so the backup files are sent/stored encrypted there.
This setup hasn't run very long yet, so I won't recommend it, but it seems to check quite a lot of boxes for me. Maybe it gives some ideas. I'm also interested what alternative solutions others came up with.