I'm trying to wrap my head around the concept of 'pulling' backups, rather than pushing them. In my mind, once you make a backup, you should then transfer it to a separate system for archival.
To pull backups, the backup system connects to the production system and grabs the data, storing it locally on the backup system. To push backups would be for the production system to connect to the backup system and send the data.
The main benefit of pull-based backups is that the production machine doesn't need credentials to write to the backup server; this means if production is compromised, it can't corrupt your backups.
If you can’t trust the production machine to initiate regular backups by itself, why do you trust the production machine to allow the backup server to access the production machine and make backups? In both cases you need an alert system to detect if a production system has not been backed up for too long.
Therefore, a push system is no different than a pull system, provided, of course, that the production system can only make new backups, not write indiscriminately to the backup server (e.g. delete old backups).
> If you can’t trust the production machine to initiate regular backups by itself, why do you trust the production machine to allow access by the backup server?
If production is compromised, you can't trust either.
> Therefore, a push system is no different than a pull system
Not entirely - a push system can DOS the backups much easier than a pull system (filling the disks, say), and a push system requires append-only backups in order to protect against backup corruption. A pull system just requires read-only access into production, which is much more simple to configure, audit, enforce, and maintain (IMO).
The main benefit of pull-based backups is that the production machine doesn't need credentials to write to the backup server; this means if production is compromised, it can't corrupt your backups.