Ah, it’s linux. I’m not a linux guy, but IIRC you want some combinations of After and WantedBy options for systemd.
Can you be sure you never connect it while encryption is silently in progress before you notice?
It may help reduce the impact somewhat. But not eliminate the risk. For example, if a single block where the config file resides rots - entire backup is gone. And that file is never re-written, only read.
Then there is correlated risk – power surge killing both drives during backup, flood, fire; so you still need offsite backup. The local one just becomes a non-critical convenience options, to save egress and and bandwidth when the source of data loss is not fire or power surge.
There is no contradiction: You can run prune from another machine (perhaps, from a cloud instance, that is only running for 5 min a month to do the prune, thus minimizing risk of compromise to obnoxiously low levels) with another set of keys, that do allow delete.
(Personally, I never delete anything, storing stuff is cheap, cost of a mistake deleting something useful prematurely is non-zero, so I’d rather pay extra $1/month for extra terabyte of garbage and not have to ever think about that. But your dataset maybe transient in nature, so pruning maybe justified)
