21–30 of 65 posts
It offers similar deduplication, indexing, per-file compression, and versioning advantages
Zpaq is quite mature and also handles deduplication, versioning, etc.
Earlier quoted context omitted.
> They protect you from accidental deletion, malware, and even just snapshots of what something looked at a particular time etc. S3 with versioning enabled provides this. I'm not being naive when I say S3 really provides everything you might need. Its my observation over the last 13 years, dealing with tons of fires, that there has every been a situation where I couldn't retrieve something from S3. Legally you might…
Insider risk is a potential reason. If someone acquires root in your AWS account, having a backup might give you options to dealing with blackmail or even malicious deletion after it happens.
Possible, perhaps, but contrived.
Earlier quoted context omitted.
Backups don't just protect you from durability issues. They protect you from accidental deletion, malware, and even just snapshots of what something looked at a particular time etc. The context that this article suggests is that if your S3 bucket is your primary storage, then it's possible that you're not thinking about where the second copy of your data should belong.
> They protect you from accidental deletion, malware, and even just snapshots of what something looked at a particular time etc. S3 with versioning enabled provides this. I'm not being naive when I say S3 really provides everything you might need. Its my observation over the last 13 years, dealing with tons of fires, that there has every been a situation where I couldn't retrieve something from S3. Legally you might…
> By contrast, S3 buckets are rarely backed up (a rather short-sighted approach for mission-critical cloud data), and even one-off archives are rarely done. This is a complete aside, but how often are people backing up data to something other than S3? What I mean is it some piece of data is on S3, do people have a contingency for "S3 failing". S3 is so durable in my mind now that I really only imagine having an "S3 b…
Perhaps reframe the problem not as data loss because S3's technical infrastructure failed but because of one of the many other ways that data can get zapped or that you might need it. For example: - Employee goes rogue and nukes buckets. - Code fault quietly deletes data, or doesnt store it like you thought. - State entity demands access to data, and you'd rather give them a tape than your S3 keys. I agree that with…
Earlier quoted context omitted.
Insider risk is a potential reason. If someone acquires root in your AWS account, having a backup might give you options to dealing with blackmail or even malicious deletion after it happens.
If someone acquires root in the AWS account, they likely then have access to the backups, too. Unless we're also assuming whatever is doing the backup runs in an alternate cloud and our attacker or insider somehow has access to only 1 of 2 clouds. Possible, perhaps, but contrived.
> By contrast, S3 buckets are rarely backed up (a rather short-sighted approach for mission-critical cloud data), and even one-off archives are rarely done. This is a complete aside, but how often are people backing up data to something other than S3? What I mean is it some piece of data is on S3, do people have a contingency for "S3 failing". S3 is so durable in my mind now that I really only imagine having an "S3 b…
How does this differ from zpaq and dwarFS? Zpaq is quite mature and also handles deduplication, versioning, etc.
Or eStargz. https://github.com/containerd/stargz-snapshotter
Or Nydus RAFS. https://github.com/dragonflyoss/nydus
Links for your mentioned zpaq and dwarFS https://www.mattmahoney.net/dc/zpaq.html https://github.com/mhx/dwarfs
https://plakar.io/posts/2025-07-07/kapsul-a-tool-to-create-a...
> By contrast, S3 buckets are rarely backed up (a rather short-sighted approach for mission-critical cloud data), and even one-off archives are rarely done. This is a complete aside, but how often are people backing up data to something other than S3? What I mean is it some piece of data is on S3, do people have a contingency for "S3 failing". S3 is so durable in my mind now that I really only imagine having an "S3 b…
Perhaps reframe the problem not as data loss because S3's technical infrastructure failed but because of one of the many other ways that data can get zapped or that you might need it. For example: - Employee goes rogue and nukes buckets. - Code fault quietly deletes data, or doesnt store it like you thought. - State entity demands access to data, and you'd rather give them a tape than your S3 keys. I agree that with…
https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiF...
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object...