Push versus Pull backups
The dirvish backup process is a "pull" model, that is, data is pulled from the clients by the server, under server control, rather than the clients initiating and controlling a "push" of data from client to server.
There are a few reasons why this is better. The main one is security; if a complete backup is performed, the entire client image is copied to the server - ssh keys and all. This makes the server the highest value security risk. If you compromise the backup server, you compromise every client machine, as well.
Thus, the server should be as secure as possible; no user logins, no inet services, no way to respond to any externally initiated event. In pull mode, the backup server treats data as data, and stores it. The server never executes or responds to data, or cares about client permissions or !UIDs or anything else. Data just gets stored. If the server detects a security problem on the local net, it even can stop asking for data, becoming completely inert until the storm has passed.
If the client initiates a push mode connection, it now has user access to the server. Even if client23 has access to the server account "backup-client23", and a very few programs in a chroot jail, it is still running common service code, and potentially could exploit security flaws in that code. If client23 is compromised, it now has a direct path to attacking the server. And once the server goes, everything goes.
Besides the security issues, there are performance reasons for running in pull mode.
Dirvish can overlap images from multiple similar machines; 20 laptops with the same /usr data, for example. There is no practical way for a client to control this.
Dirvish initiates backups sequentially, vault by vault. Although the rsync process can launch multiple parallel network connections to maximize throughput, dirvish does not do multiple machines at once. This allows the server to control the network load, and minimize the total time needed for backups. The clients would have to be far more sophisticated to handle this load.
The bottom line is, a backup server has complete root access to the client, because even if it cannot log in, the backup server can still examine *all* the client data. No security is gained for the client by eliminating it's ssh inbound capabilities.
There is one tactical reason for running a Push client, though. Windows. Some windows clients are unable to act as servers, meaning that they can only push data. In this case, it might be best to have the client create some kind of tunnel to an expendable "middle" machine that the server can connect to. The middle machine might get compromised, but if the data passes through it in an ssh pipe, the middle machine can't do anything with it!