3 ms·

Yes, but which server will run the purge command? It cannot be the same server as the one you are backuping, since one of the goal of the backup is to protect t

Yes, but which server will run the purge command? It cannot be the same server as the one you are backuping, since one of the goal of the backup is to protect the server if it is compromised.

Erlich_Bachman 7y ago
You can run command from inside your backup script, from the client. It needs the encryption key anyway to add backups, this way it is just one extra command that does all the pruning (quite quickly as well). And you don't have to worry about full/incremental backups, nor really about any "rotation" or managing them manually, it's all deduplicated and Borg just keeps X number of daily/weekly/whatever snapshots (like duplicacy, like restic, like bup, etc. etc.).
- ngrilly 7y ago
  Yes, I got this. But if your server is compromised, then the attacker can erase your backups, which ruins the point of doing backups in the first place. This is why there is an append-only mode.
  - Erlich_Bachman 7y ago
    Don't rely on append-only mode in Borg, it does not work really as advertised. Every transaction in that mode is recorded in a log, which if you are very careful you can go back into (but even reading or monitoring it is a PITA, the "interface" requires you to carefully track id's of files and check with dates etc). And being careful is difficult, because in Borg, once you do any other backup command from a full access account (for example to do pruning) - it will automatically, no warning, go through the log and apply it. You should really really read up on that functionality first before relying on it, the way Borg has implemented it is close to anti-feature. Regarding compromisation of strictly the server itself, I believe there are commands to check the state of the repository? Isn't that enough?
  - corobo 7y ago
    I don’t know the best method, but my method is to have a locked down backup box in the same DC as the machine(s) it’s backing up. It mounts the machine to be backed up and runs Borg on that. The backup machine does need locking down in of itself but that’s a lot easier to do than locking down something public facing
  - majewsky 7y ago
    What I do is to have two different SSH keys. The one that is used by the backup script is --append-only. The one that I keep locally on my notebook has full access, so I `borg prune` from there when I see the disk usage reaching critical levels.
  - aljungberg 7y ago
    If we are still talking about rsync.net, and an attacker gains access to your account and deletes your borg archive, you can still restore your backup from the rsync.net ZFS snapshots. The snapshots are not deletable even with your full credentials.

Yes, but which server will run the purge command? It cannot be the same server as the one you are backuping, since one of the goal of the backup is to protect the server if it is compromised.

Erlich_Bachman 7y ago

You can run command from inside your backup script, from the client. It needs the encryption key anyway to add backups, this way it is just one extra command that does all the pruning (quite quickly as well). And you don't have to worry about full/incremental backups, nor really about any "rotation" or managing them manually, it's all deduplicated and Borg just keeps X number of daily/weekly/whatever snapshots (like duplicacy, like restic, like bup, etc. etc.).

ngrilly 7y ago
Yes, I got this. But if your server is compromised, then the attacker can erase your backups, which ruins the point of doing backups in the first place. This is why there is an append-only mode.
- Erlich_Bachman 7y ago
  Don't rely on append-only mode in Borg, it does not work really as advertised. Every transaction in that mode is recorded in a log, which if you are very careful you can go back into (but even reading or monitoring it is a PITA, the "interface" requires you to carefully track id's of files and check with dates etc). And being careful is difficult, because in Borg, once you do any other backup command from a full access account (for example to do pruning) - it will automatically, no warning, go through the log and apply it. You should really really read up on that functionality first before relying on it, the way Borg has implemented it is close to anti-feature. Regarding compromisation of strictly the server itself, I believe there are commands to check the state of the repository? Isn't that enough?
- corobo 7y ago
  I don’t know the best method, but my method is to have a locked down backup box in the same DC as the machine(s) it’s backing up. It mounts the machine to be backed up and runs Borg on that. The backup machine does need locking down in of itself but that’s a lot easier to do than locking down something public facing
- majewsky 7y ago
  What I do is to have two different SSH keys. The one that is used by the backup script is --append-only. The one that I keep locally on my notebook has full access, so I `borg prune` from there when I see the disk usage reaching critical levels.
- aljungberg 7y ago
  If we are still talking about rsync.net, and an attacker gains access to your account and deletes your borg archive, you can still restore your backup from the rsync.net ZFS snapshots. The snapshots are not deletable even with your full credentials.