If the main site gets compromised the credentials there must be considered lost and known to che attackers.
with a pull backup that’s not an issue because the main site has no access to the remote system; it is a process on the remote site that has credentials to access the main site and not the other way around.
the remote system may receive a compromised copy of the data, but the attacker cannot tamper with previous backups so recovery is still possible.
bcnelson@lemmy.world 3 weeks ago
The reasoning is that your backup server should be more secure than production. Production has to have a bunch of stuff open in order to be useful and convenient. The backup server does not. It can be basically fully locked down.
Onomatopoeia@lemmy.cafe 3 weeks ago
To add - by doing pulls the backup server uses different credentials to run than the credentials used to perform pulls.
Backup server has it’s own credentials database, machines being backed up have their own database. Backup service in backup server uses appropriate credentials from machine being backed up to access the data there (shares, etc). So credentials from compromised machine are unrelated to credentials for backup server.
And if backups are done properly (full on a schedule, daily incrementals, or something similar) you should be able to revert to a known-good state with minimal data loss.