3 ms·

Hmmm from what I understand zrepl can do copy of source to backup both in a push or pull mode. I would say the push mode is still a very fragile way to do backu

Hmmm from what I understand zrepl can do copy of source to backup both in a push or pull mode. I would say the push mode is still a very fragile way to do backups. Imagine source machine is compromised and attacker decide to delete/encrypt your data, and see there is a backup mechanism connecting to the backup machine, what prevents him from using the deleting/encrypting the backups as well? You'd definitely want the backup machine to pull the snapshots, and have no way to connect to it from source machine directly with a user that would have access to the data or an admin account. That means no ssh keys on the source machine, no password kept in a password manager that would be loaded on the source machine either. Another strong method would involve 3 machines: source --push--> replica1 <--pull-- replica2 Where source and replica1 would have ZFS filesystem and snapshots while replica2 is using a different filesystem (LVM + ext4 ) and snapshots to safeguard from replicating bugs that lead to data not being available. ZFS snapshots could be saved as individual files on this filesystem.

justinclift 3y ago
> ... what prevents him from using the deleting/encrypting the backups as well? With ZFS snapshots the older snapshots would still be present on the target server, in their unencrypted form. > That means no ssh keys on the source machine ... Typically for non-user logins (eg script access and similar) you do the extra step of configuring the receiving ssh to only allow a specific command for a given key. It's a configurable ssh thing, where you add extra info to the .ssh/authorized_keys file on the destination server. With that approach, it doesn't allow general user logins while still allowing the source machine to send the data.
- prmoustache 3y ago
  > With ZFS snapshots the older snapshots would still be present on the target server, in their unencrypted form. Only and only if you apply best practicies mentionned above in the second point of your post. Anyway I'd rather protect my backup as much as I can and not allow the source machine to have any direct access to an account on the backup server because of possible security. Security is hard sometimes and you never know when some bugs might increase the possibilities. I like my backup servers to not have any open port. The caveat is that it is only possible if your primary backup server is locally and physically accessible. If you are travelling you might want to be able to access it without being physically present. An option might be to just have ssh disabled when you are at home and you enable the service when you know you won't be at home for a long enough period to make it a problem if you need to restore data.
  - justinclift 3y ago
    > Anyway I'd rather ... That's fair, it's a different risk profile, and one that you're happy with. Nothing wrong with that. :)

justinclift 3y ago

> ... what prevents him from using the deleting/encrypting the backups as well? With ZFS snapshots the older snapshots would still be present on the target server, in their unencrypted form. > That means no ssh keys on the source machine ... Typically for non-user logins (eg script access and similar) you do the extra step of configuring the receiving ssh to only allow a specific command for a given key. It's a configurable ssh thing, where you add extra info to the .ssh/authorized_keys file on the destination server. With that approach, it doesn't allow general user logins while still allowing the source machine to send the data.

prmoustache 3y ago
> With ZFS snapshots the older snapshots would still be present on the target server, in their unencrypted form. Only and only if you apply best practicies mentionned above in the second point of your post. Anyway I'd rather protect my backup as much as I can and not allow the source machine to have any direct access to an account on the backup server because of possible security. Security is hard sometimes and you never know when some bugs might increase the possibilities. I like my backup servers to not have any open port. The caveat is that it is only possible if your primary backup server is locally and physically accessible. If you are travelling you might want to be able to access it without being physically present. An option might be to just have ssh disabled when you are at home and you enable the service when you know you won't be at home for a long enough period to make it a problem if you need to restore data.
- justinclift 3y ago
  > Anyway I'd rather ... That's fair, it's a different risk profile, and one that you're happy with. Nothing wrong with that. :)