5 ms·

Sounds like it's just a worse Glacier setup then? Amazon has Pre-Pay in a semi-open beta. CloudFront has 1TB/month free- knocking a large chunk of a restore's

Sounds like it's just a worse Glacier setup then? Amazon has Pre-Pay in a semi-open beta. CloudFront has 1TB/month free- knocking a large chunk of a restore's cost. (Note- you should have either encrypted your stuff yourself and/or S3 authorization/access control still works over CF) At what seems to be <$2/mo per TB ($1/TB glacier Deep archive + 9cent/gb for metadata on S3 frequent access), no other solution comes close. The big issue is the lump cost of a restore. Which, is quickly worn down by being > $5/TiB/mo cheaper than anybody else.

amluto 1y ago
Tarsnap has a nice security model, and it’s quite a challenge to convince any open-source tool to match it.
- dividuum 1y ago
  restic is basically identical and you can choose where you store your data.
  - amluto 1y ago
    restic can supposedly be set up to prevent a corrupted / compromised client from destroying old data using S3 versioning policy, but this doesn’t appear to be a well-supported feature with clearly-described security properties. Tarsnap, in contrast, has an explicit first-class ability to prevent a compromised client from damaging old backups.
    - placardloop 1y ago
      That’s because restic is not opinionated about where and how you store your backups. Restic provides a nice interface to create the backups, and then lets you choose where you want to store them (and how access to them is managed), be it locally or via SFTP or S3 or many other backends. Any security properties related to S3 are not in the scope of what restic is meant to do. It’s pretty simple to enable versioning and object lock on your S3 bucket, but it is another step if you’re using restic. Sure, if you just want all of that taken care of for you, you can use tarsnap, but you’re paying a 5x+ premium for it. The other nice thing about restic is that since it’s just the client-side interface, it allows others to provide managed storage. Borgbase.com is a storage backend that is supported by Restic that supports append-only backups, and is cheaper than tarsnap.
      - amluto 1y ago
        I disagree, strongly. Here are the relevant docs: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#amazon-s3 https://restic.readthedocs.io/en/stable/030_preparing_a_new_... I would like to see an explicit discussion of what permissions are needed for what operation. I would also like to see a clearly specified model in which backups can be created in a bucket with less than full permissions and, even after active attack by an agent with those same permissions, one can enumerate all valid backups in the bucket and be guaranteed to be able to correctly restore any backup as long as one can figure out which backup one wants to restore. Instead there are random guides on medium.com describing a configuration that may or may not have the desired effect.
        placardloop 1y ago
        Again, this isn’t at all in the scope of restic’s docs. If you’re using S3 as the storage, it’s on you to understand how S3 works and what permissions are needed, just like it’s on you to understand how your local file system works and file permissions work if you use the local file system as a backend. If you don’t understand S3 or don’t want to learn, then that’s fine, and you can pay the premium to tarsnap for simplifying it for you. But that’s your choice, not an issue with restic. If you think differently, have you submitted a PR to restic’s docs to add the information you think should be there?
        privatelypublic 1y ago
        Interesting play on the debate- but after the response to restic's original decision to upstream Object Store permissions and features... to the Object Store, along with my attempts to explain S3 to several otherwise reasonably technical people.... I think people are frequently trapped in some way of thinking (not sure exactly) that doesn't allow them to think of storage as anything other than Block based. They repeatedly try to reduce S3 to LBA's, or POSIX permissions (not even modern ACL type permissions), or some other comparison that falls apart quickly. Best I've come up with is "an object is a burned CD-R." Even that falls apart though
        1y ago
    - dividuum 1y ago
      Fair enough. Personally I use an ssh target with zfs file system with its own automatic snapshots. The restic snapshots don’t directly correspond to the zfs snapshots, but I can live with that.

amluto 1y ago

Tarsnap has a nice security model, and it’s quite a challenge to convince any open-source tool to match it.

dividuum 1y ago
restic is basically identical and you can choose where you store your data.
- amluto 1y ago
  restic can supposedly be set up to prevent a corrupted / compromised client from destroying old data using S3 versioning policy, but this doesn’t appear to be a well-supported feature with clearly-described security properties. Tarsnap, in contrast, has an explicit first-class ability to prevent a compromised client from damaging old backups.
  - placardloop 1y ago
    That’s because restic is not opinionated about where and how you store your backups. Restic provides a nice interface to create the backups, and then lets you choose where you want to store them (and how access to them is managed), be it locally or via SFTP or S3 or many other backends. Any security properties related to S3 are not in the scope of what restic is meant to do. It’s pretty simple to enable versioning and object lock on your S3 bucket, but it is another step if you’re using restic. Sure, if you just want all of that taken care of for you, you can use tarsnap, but you’re paying a 5x+ premium for it. The other nice thing about restic is that since it’s just the client-side interface, it allows others to provide managed storage. Borgbase.com is a storage backend that is supported by Restic that supports append-only backups, and is cheaper than tarsnap.
    - amluto 1y ago
      I disagree, strongly. Here are the relevant docs: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#amazon-s3 https://restic.readthedocs.io/en/stable/030_preparing_a_new_... I would like to see an explicit discussion of what permissions are needed for what operation. I would also like to see a clearly specified model in which backups can be created in a bucket with less than full permissions and, even after active attack by an agent with those same permissions, one can enumerate all valid backups in the bucket and be guaranteed to be able to correctly restore any backup as long as one can figure out which backup one wants to restore. Instead there are random guides on medium.com describing a configuration that may or may not have the desired effect.
      - placardloop 1y ago
        Again, this isn’t at all in the scope of restic’s docs. If you’re using S3 as the storage, it’s on you to understand how S3 works and what permissions are needed, just like it’s on you to understand how your local file system works and file permissions work if you use the local file system as a backend. If you don’t understand S3 or don’t want to learn, then that’s fine, and you can pay the premium to tarsnap for simplifying it for you. But that’s your choice, not an issue with restic. If you think differently, have you submitted a PR to restic’s docs to add the information you think should be there?
        privatelypublic 1y ago
        Interesting play on the debate- but after the response to restic's original decision to upstream Object Store permissions and features... to the Object Store, along with my attempts to explain S3 to several otherwise reasonably technical people.... I think people are frequently trapped in some way of thinking (not sure exactly) that doesn't allow them to think of storage as anything other than Block based. They repeatedly try to reduce S3 to LBA's, or POSIX permissions (not even modern ACL type permissions), or some other comparison that falls apart quickly. Best I've come up with is "an object is a burned CD-R." Even that falls apart though
        1y ago
  - dividuum 1y ago
    Fair enough. Personally I use an ssh target with zfs file system with its own automatic snapshots. The restic snapshots don’t directly correspond to the zfs snapshots, but I can live with that.