Yes, restore would also need that option… if you need automated/scripted operation. If you prefer, an env variable can be set with the passphrase and then echo the var (instead of a tmp file).
Only restore has this restriction (it will even stop the VMs you are restoring). With backup, it uses the Qubes snapshot the system took when you last started/stopped that VM. So if the VMs is running during backup it won’t see changes you made since you started the VM, but otherwise there is no conflict in backing up a running VM.
Thin LVM (or ‘lvmthin’) tends to grossly underestimate the amount of metadata it will need to track changes as lv snapshots are saved and written to. Although newer Qubes installers have tried to address this by extending the ‘tmeta’ by a certain percentage, I’ve found that about 3X the original metadata size (which can be increased with lvextend --poolmetadatasize) is required to handle both Qubes internal and backup-related snapshots without incident. BTW, the ‘tock’ snapshots are temporary and generally should not hang around (they do only when there is a crash, and Wyng removes them when possible); the ‘tick’ snapshots are the ones that persist, one per volume. I think a factor in all this is that Qubes now keeps more of it own snapshots than it did in the past.
My general recommendation on Qubes is to use Btrfs instead of (or as the default pool in addition to) LVM. In general there is far less hassle and risk.
Also, see my notes that I’ll be posting to the Wyng issue 184.