I've been using tarsnap for years and am in the process of migrating away from it.
Things that are not cozy:
1) There's no way to monitor your monthly spend per host/credit left on the account/etc. apart of logging into your account in a browser and manually keeping a spreadsheet. There's no web API to do it. You get an email warning when you have about 7 days of credit left. That's it.
2) Nothing is "a precious few megabytes" anymore. What seems like a negligible monthly spend at first can quickly grow up on you and soon you're spending highly non-trivial amounts. Which you might not notice due to 1) unless you are diligent in your accounting.
3) tarsnap restores are slow. Really really slow. A full restore can take days if you have non-trivial amounts of data (and make sure you have enough credit in your account to pay for that server-to-client bandwidth!) My understanding is that throughput is directly related to your latency to the AWS datacenter where tarsnap is hosted. Outside of north America you can be looking at nearly dial-up speeds even on a gigabit link.
Again, a problem that can surprise you at the most inconvenient time. Incremental backups in a daily cronjob tend to transfer very small amounts of data, so you won't notice the slowness until you try to do a full restore. And you generally don't test that very often because you pay for server-to-client transfers.
There are some workarounds for 3) and there's a FAQ about it, but look at the mailing list and you'll see that it's something that surprises people again and again.
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.
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.
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.
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.
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?
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
I still completely disagree. It’s on me to understand IAM. It should not be on me to understand the way that restic uses S3 such that I can determine whether I can credibly restore from an S3 bucket after a compromised client gets permission to create objects that didn’t previously exist. Or to create new corrupt versions of existing objects.
For that matter, suppose an attacker modifies an object and replaces it with corrupt or malicious contents, and I detect it, and the previous version still exists. Can the restic client, as written, actually manage the process of restoring it? I do not want to need to patch the client as part of my recovery plan.
(Compare to Tarsnap. By all accounts, if you backup up, your data is there. But there are more than enough reports of people who are unable to usefully recover the data because the client is unbelievably slow. The restore tool needs to do what the user needs it to do in order for the backup to be genuinely useful.)
I think you two may be talking past each other a bit here. Bear in mind I am not a security expert, just a spirited hobbyist; I may be missing something. As stated in my digital resilience audit, I actually use both Tarsnap and restic for different use cases. That said:
Tarsnap's deduplication works on the archive level, not on the particular files etc within the archive. Someone can set up a write-only Tarsnap key and trust the deduplication to work. A compromised machine with a write-only Tarsnap key can't delete Tarsnap archive blobs, it can only keep writing new archive blobs to try to bleed your account dry (which, ironically, the low sync rate helps protect against - not a defense for it, just a funny coincidence).
restic by contrast does do its dedupe at the file level, and what's more it seems to handle its own locks within its own files. Upon starting a backup, I observe restic first creates a lock and uploads it to my S3 compatible backend - my general purpose backups actually use Backblaze B2, not AWS S3 proper, caveat emptor. Then restic later attempts to delete that lock and syncs that change too to my S3 backend. That would require a restic key to have both write access and some kind of delete access to the S3 backend, at a minimum, which is not ideal for ransomware protection.
Many S3 backends including B2 have some kind of bucket-level object lock which prevent the modification/deletion of objects within that bucket for, say, their first 30 days. But this doesn't save us from ransomware either, because restic's own synced lock gets that 30 day protection too.
I can see why one would think you can't get around this without restic itself having something to say about it. Gemini tells me that S3 proper does let you set delete permissions at a granular enough level that you can tell it to only allow delete on locks/, with something like
# possible hallucination.
# someone good at s3 please verify
{
"Sid": "AllowDeleteLocksOnly",
"Effect": "Allow",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::backup-bucket/locks/*"
}
But, I have not tested this myself, and this isn't necessarily true across S3 compatible providers. I don't know how to get this level of granularity in Backblaze, for example, and that's unfortunate because B2 is about a quarter the cost of S3 for hot storage.
The cleanest solution would probably be to have some way for restic to handle locks locally, so that locks never need to hit the S3 backend in the first place. I imagine restic's developers are already aware of that, so this seems likely to be a much harder problem to solve than it first appears. Another option may be to use a dedicated, restic-aware provider like BorgBase. It sounds like they handle their own disks, so they probably already have some kind of workaround in place for this. Of course, as others have mentioned, you may not get as many nines out of BB as you would out of one of the more established general-purpose providers.
P.S.: Thank you both immensely for this debate, it's helped me advance the state of my own understanding a little further.
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.
restic, and my own computers and storage, and the occasional rented device (VPS or similar, typically)
i find that the hassle of setting up my stuff is still preferable than having to worry about managing bills, subscriptions, and third parties just changing their policies
Is it stable? I've been using restic for a while, and I'm interested in rustic, but I have no idea how stable it is overall. Obviously it's still in beta so I won't use it in prod but curious what others experiences have been like.
I also switched away from Tarsnap because I needed to restore my personal PDF collection of like 20GB once and my throughput was like 100Kb/s, maybe less. It has been a problem for at least a decade, with no fix in sight.
I'm carefully monitoring plakar in this space, wondering if anyone has experience with it and could share?
The pricing isn’t due to AWS. Even if you used standard S3 and paid for data retrieval for your entire backup every single month, tarsnap is over 3x the price of just using S3 yourself. The markup on tarsnap is wild.
Using something like restic or borgbackup+rclone is pretty much the same experience as tarsnap but a fraction of the price.
Yeah that pricing is crazy for something without any of the security that comes with using a BigCo. I've bounced off it in the past as soon as I got to their cutesy pricing model but I just played with the calculator linked here to model my needs -- three thousand USD a year for 1Tb of cold storage??
I appreciate you using the calculator! It's at [1] for anyone who wants to futz around with it.
$3000 per TB-year is accurate to my knowledge, and yes, it is at least one, and probably two, orders of magnitude what you can get with more general purpose systems. Backblaze B2 is $72 per TB-year; AWS Glacier is $12 per TB-year I believe; purchasing two 20 TB Seagate drives for $300 apiece, mirroring them, and replacing them every 3 years gives you about $10 per TB-year (potentially - most of us don't have 20 TB to back up in our personal lives). Those are the best prices I've been able to find with some looking [2].
To me, when I was building out the digital resiliency audit, the pricing and model just seemed to tell me that tarsnap was for very specific kinds of critical data backups, and was not a great fit for general purpose stuff. Like a lot of other people here I also have a general-purpose restic based 3-2-1 backup going for the ~150 GB in /home I back up. [3] My use of tarsnap is partly a cheap hedge for the handful of bytes of data I genuinely cannot afford to lose against issues with restic, Backblaze B2, systemd, etc.
Tarsnap has always been expensive. More than a decade ago (April 2014, to be precise), @patio11 suggested that tarsnap should increase its pricing. [1] Here’s the HN thread on that post. [2]
All the granular calculations (picodollars) on storage used plus time are fine. But tarsnap was always very expensive for larger amounts of data, especially data that cannot be well deduplicated.
Do they charge for actual bandwidth as well? Seems like it. From tarsnap.com:
> Tarsnap uses a prepaid model based on actual usage: Storage: 250 picodollars / byte-month of encoded data ($0.25 / GB-month)
Bandwidth: 250 picodollars / byte of encoded data ($0.25 / GB)
OP's cost estimator tells me it would cost a cool $250 per month to keep a terabyte of data backed up in Tarsnap. The same amount costs me $8.25 per month with Backblaze. That's not very cozy!
OP here, thanks for using the cost estimator! [1] I'm glad you got some use out of it.
I use Backblaze B2 myself for most of my general purpose backup needs. It's actually $6/month, I believe.
Tarsnap fills but one niche in my overall system. It's a very important niche for which I haven't found any other providers who do anything similar (keyfiles, prepaid, borderline anonymous etc), but it's not where I store the vast majority of my stuff.
I just don't really understand what the niche is. If you have a tiny bit of data that you want to keep backed up and rarely access, you can encrypt it with any number of easy command-line or GUI tools and upload it to Google Drive, Dropbox, or anywhere else with a free tier. If it's securely encrypted, there's no reason to care that the storage provider knows who you are. Tarsnap definitely has nerd appeal, but I can't think of a real problem that it actually solves.
I readily admit I'm a nerd about this stuff, and this is primarily a hobby of mine. I am explicitly not 80/20'ing this because it's fun. [1]
One use case: I don't like the idea of having any accounts at all which I log into without the aid of a password manager. That creates a bootstrapping problem - how am I supposed to log into Google Drive to get my Google Drive password? A prepaid keyfile-based model is one particularly robust way of solving this. You stick your e.g. 100 kB password database in there, print out and shred the keyfile, stick the printout in a fireproof safe, and be virtually certain that whatever you put in Tarsnap has been untouched however many years you come back to it later. Print it on archival paper with some silica gel packets and it might survive for millennia in your weird subterranean vampire family castle.
"The business won't survive that long." I'm not so sure. Its ongoing costs appear minimal, and it generates eye watering amounts of float. $5 paid today is >$200 fifty years from now when compounded at 8% real interest. That very fact makes it much more likely that Tarsnap actually will survive for those 50 years, which should make us more likely to trust it, which... You see where this is going. This is one of those things where aggressively pricing too close to the bare metal costs might actually be a bad thing to a very important subset of users. One might even make the argument that, if the margins are as good as I'm supposing they are, then depending on the goals of the founder, Tarsnap is more likely to outlive S3 than S3 Tarsnap.
You're on the right path! Alas, I am a heretic and think recovery codes under my approach may cause more problems than they solve. [1]
Caution may be justified when it comes to doing this for something with as wide a surface area as a Google account. For me, if I'm going to have to compromise on 2FA somewhere anyway, I might as well go full hog and get an honest to goodness keyfile.
I actually do that. I have two folders one synced up to Dropbox and another to iCloud and they are encrypted with Cryptomator. But I back up the mounted folders i.e data to tarnsap. Besides those encrypted files (fragments?) of Cryptonator were messed up by both iCloud and Dropbox over the last few years. Gratned it could be Restic and Borg (I use these two as well for larger data sets), but for very small data tarsnap has woked well for me and prices are tiny. For a larger data set, I won't pick tarsnap.
If there's an simple but "solid" GUI backup tool with (true) PAYG I'd migrate away from Tarsnap, but there isn't one.
I used tarsnap for years, but as my data got bigger and I really wanted to have multipe offsite backups with different providers, I moved to restic.
I loved tarsnap - it's a great product. But restic feels very similar but you can backup to your local HD, a remote HD, or "the cloud" and everything is the same CLI commands.
I use borgbase (they support restic) - backblaze with their s3 backend, and my own servers. So server A will copy to server B and vis-versa every ~10 minutes snapshot for quick/easy restoration should it be necessary, then nightly backups to borgbase/backblaze.
The interface is nice but it is excruciatingly slow at restores. I had to switch to borg, which has an extremely similar feature set but performs much better (and you can bring your own hardware).
I'm really surprised to hear that the slow restore times from tarsnap are still as big a problem now as they were a decade ago when I last used it. I absolutely loved the interface and the security model, and I was willing to pay at the (very) premium price point, but it was just too impractical trying to restore anything from it at the speeds I could achieve. (If I remember right, there was some problem with the design which meant normal latency between the client and the server tanked throughput to crazily low levels.)
I really wanted to like Tarsnap and gave it a good hard look for my backup needs. Ultimately my problem was that there's no way for me to gauge how much the service will cost me. Going just by the amount of data in my home dir, it would be cost prohibitive to upload to Tarsnap. The site does assure me that thanks to compression and deduplication, the actual cost will be far less than I might estimate, which is great! But also, as far as I can tell there's no way to have the client give me an estimate of "here's how much data you actually have once the secret sauce is applied". So while the dedup and compression might make the costs far more reasonable, I won't actually know until I pay to store some data. Which means I might find that suddenly I owe Colin a lot of money if the size savings aren't very big due to my data not being very amenable to those measures. That's not a risk I'm willing to take, so ultimately I pursued other options.
will tell you the compressed size of your deduplicated data, which gives you the upload cost and first-month cost. 4GB of files usually works out to 3GB of dedup/compressed archive data for most people, less for people with many similar files.
It depends on what you're after and what you're using it for. I broke down the costs I forecast for myself over the next decade at https://andrew-quinn.me/digital-resiliency-2025/#postscript-... and found tarsnap is unlikely to cost me more than 50 cents for my usecase. Backblaze B2 will cost me about $70-80 over the next 10 years, but it has many orders of magnitude more data to back up.
The cheapest I can find for a consumer buying e.g. 20TB Seagate hard drives and rotating them every 3 years or so is about $5 per TB-year, without mirroring. So if raw storage cost optimization is what you're after that's what I'd go for to start. Even AWS Glacier doesn't come close to that, although you do get other things with it.
it's expensive but it doesn't have a monthly base cost, doesn't require you to run a server etc.
through you want at least one backup of yours to be off site, and your want your backups robust, so comparing hard drive cost seem strange as if you run the backup server yourself you need a decent raid and for the offline backup you need to compare with idk. S3 storage cost or similar
it's still more expensive but if you only need to backup some folders of documents or similar it might anyway be the simpler and cheaper solution
if you want to backup huge photo/video/vm image collections it probably isn't the best choice for you
A hard drive under the bed is not the only alternative to tarsnap, you can use any of its numerous competitors that are also maintained by professionals, whose whole business is also running a backup service. Say rsync.net or borgbase, which are at least 10× cheaper than tarsnap last time I compared them, and can be used with restic or borg which are much faster at restoring even relatively small amounts data (forget if we're talking terabytes, it's "weeks" vs "your link speed").
I think tarsnap was a good service about 20 years ago when it had little competition, but using it now makes very little sense IMHO. You can donate to its awesome FreeBSD maintainer, or to FreeBSD, directly.
> A hard drive under the bed is not the only alternative to tarsnap
Also you can back up to the hard drive under your friend's bed, and they can back up to the hard drive under your bed.
If you're even slightly technical, or have a friend who is, I'd recommend both of you buying the cheapest Kirkwood NASes you can find on ebay, throwing Debian on them, and becoming each other's backup buddies.
That's what I do! I have a couple of friends from college and we back up to each other over a VPN. It's a very nice solution to the off-site backup need.
Borgbase had a week long (IIRC) outage due to a failed attempt to add new drives to an array. As far as I know they never published a post-mortem on this and have never discussed how they're going to improve their disaster recovery so it can't happen again. It's difficult to recommend when they could leave you without working backups for an entire week.
I don't actually know what the bus factor for Tarsnap's infrastructure is. 2 is just the absolute lower bound from what I know of the company itself. It is in all likelihood much higher.
I can't read the founder's mind, but if I were them I would probably have some Kongō Gumi style designs on making it a 1000-year company just because that's a fun intellectual exercise. [1]
This sounds cool, but the other comments here are concerning. I've been considring Hetzner's Storage Box, as it's cheap and I could use just about anything to backup my stuff – although I prefer restic.
Storage Box with Borg backup can be setup to work almost identically to tarsnap.
The only real security feature missing is write-only access to the repository (Borg backup in theory supports it, but in practice it's impossible to use it in a way that prevents a compromised host from deleting it's backups - like tarsnap does).
In theory it is less reliable than tarsnap (AWS S3 compared to a single copy on a Hetzner's drive).
Storage Box is significantly cheaper for any kind of real-life backup sizes in my experience.
Borg requires more work to setup and configure compared to tarsnap. There's typically some scripting involved that's unique to your setup and I found that I had more documentation to study before I understood how to use Borg correctly.
A know a few people that have very low opinion of Borg's code quality and stay away from it because of it (I haven't studied it first hand)
I use restic. Restic offers everything advertised on the tarsnap website (deduplicated snapshots, e2e encryption). I pay $6 per terabyte per month using backblaze's cloud object storage. Wasabi offers 1TB at $7/mo. S3 costs $26/mo, but glacier is only $3.6/mo.
Storing one terabyte of data in tarsnap costs $250 per month.
Tarsnap's model is an ideal fit for a very small subset of the data I'm interested in safeguarding for the future. https://andrew-quinn.me/digital-resiliency-2025/ goes into it in a lot more detail.
If you're interested in safeguarding data for the future, then I don't think the model of “my backup immediately disappears once the account runs out of money” gives me anything resembling a cozy feeling at all.
That's actually one of my favorite features. That should never happen under the limited circumstances I use it for. If something goes so wrong that my account actually runs out of money before I notice, then I far prefer the default to be "intruder alert, intruder alert, wipe everything". There's a reason it's marketed as backups for the truly paranoid.
For me, personally? I do it for kicks. But in general, there do exist many data loads in the world which are valuable to the holder, valuable enough to be worth the low cost of a backup, up until time T in the future. After T, however, they become more of a liability than an asset to hold. A self-destructing backup model is the obvious fit for such situations. Both the positive-sum and the negative-sum periods need to be considered to truly safeguard your data properly.
I love thumb drives, but Tarsnap is cheaper than the expected 10 year lifetime of a fresh and well maintained thumb drive for the kind of data I hold in there by about a factor of 20 (50 cents vs $10).
It also doesn't require a UL Class 125 fireproofed safe to survive a house fire, but that's splitting hairs and getting into hobbyist territory.
I've been using Tarsnap for almost a decade for a small, but very important, personal data subset.
Tarsnap is very resilient; it doesn't do a lot, but what it does is solid. The mailing list is helpful, and you can reach out to its creators directly for prompt, useful responses if that is something you don't want on the mailing list (where names and email addresses are in the clear; use marc.info to search in it).
But if you are trying to start with Tarsnap, you should note a few things from the beginning:
- If you are looking for a completely (or even almost) frictionless backup experience - this is not it. Also, it doesn't have tons of features - which might be a good thing, but you should know and accept it.
- If you're used to tools like Backblaze, CrashPlan, Restic, or Borg, the limited feature set might frustrate you.
- Knowing this in advance will help you set expectations within its feature set. The doc/man pages are great resources once you actually read it.
- It has some quirks (may or may not be bugs) that require tinkering with your settings, env etc. Getting your hands dirty with sample data first is a great way to know Tarsnap.
- Set up your logs and scripts such that you can know/debug things later.
- Naming of your archives is important.
- You'll need at least two keys: a master key with read, write, and delete access on your archives/Tarnsap storage, and a un-passphrased regular key with only "write" permission for backups. Keep both safe, especially the master key. There's "nuke" as well…
- I used its GUI for the longest time but would absolutely not recommend it. It hides a lot, which might come back to bite you, and is not the most polished tool of all. Its last release was 7 years ago.
OP says:
> … If you use it solely to back up the few megabytes of “crown jewels” data we all have lying around"
and I actually use Tarsnap exclusively for my "crown jewels," which are in the early three digit MBs.
- So, unlike what many say, I do believe it is costly for today's storage/bw prices, especially if your data isn't very compressible. Tarsnap's compression is great, but not magic. However, i doesn't cost an exponential bomb either. Killer de-dupe though.
- You must have a plan for what and how much you want to back up, and the expected growth of that data.
- It is definitely not a "fire and forget" tool (and you should never forget your backups anyway).
I was frustrated with it until I gave up on the GUI, embraced the CLI/cron, reduced the amount of data being backed up and excluded (using copy and delete) some data being stored, and accepted what it can't do. Which is not really great but that's what it is.
Glaring omissions, IMHO: very few maintenance features (the scripts listed are not easy to work with), (almost?) no way of knowing what file changed in a certain archive, slow restores (may matter for a bigger data set), and the lack of an updated, polished GUI tool which I think is very important for personal data backup.
My request to cperciva would be: please consider this - while it's inspired by tar and stays close to it, it's also a cloud backup tool. Treating it a bit more like a modern cloud backup tool could be useful. Just my two cents.
I've been using tarsnap for years and am in the process of migrating away from it.
Things that are not cozy:
1) There's no way to monitor your monthly spend per host/credit left on the account/etc. apart of logging into your account in a browser and manually keeping a spreadsheet. There's no web API to do it. You get an email warning when you have about 7 days of credit left. That's it.
2) Nothing is "a precious few megabytes" anymore. What seems like a negligible monthly spend at first can quickly grow up on you and soon you're spending highly non-trivial amounts. Which you might not notice due to 1) unless you are diligent in your accounting.
3) tarsnap restores are slow. Really really slow. A full restore can take days if you have non-trivial amounts of data (and make sure you have enough credit in your account to pay for that server-to-client bandwidth!) My understanding is that throughput is directly related to your latency to the AWS datacenter where tarsnap is hosted. Outside of north America you can be looking at nearly dial-up speeds even on a gigabit link.
Again, a problem that can surprise you at the most inconvenient time. Incremental backups in a daily cronjob tend to transfer very small amounts of data, so you won't notice the slowness until you try to do a full restore. And you generally don't test that very often because you pay for server-to-client transfers.
There are some workarounds for 3) and there's a FAQ about it, but look at the mailing list and you'll see that it's something that surprises people again and again.
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.
Tarsnap has a nice security model, and it’s quite a challenge to convince any open-source tool to match it.
restic is basically identical and you can choose where you store your data.
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.
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.
I disagree, strongly. Here are the relevant docs:
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.
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?
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
I still completely disagree. It’s on me to understand IAM. It should not be on me to understand the way that restic uses S3 such that I can determine whether I can credibly restore from an S3 bucket after a compromised client gets permission to create objects that didn’t previously exist. Or to create new corrupt versions of existing objects.
For that matter, suppose an attacker modifies an object and replaces it with corrupt or malicious contents, and I detect it, and the previous version still exists. Can the restic client, as written, actually manage the process of restoring it? I do not want to need to patch the client as part of my recovery plan.
(Compare to Tarsnap. By all accounts, if you backup up, your data is there. But there are more than enough reports of people who are unable to usefully recover the data because the client is unbelievably slow. The restore tool needs to do what the user needs it to do in order for the backup to be genuinely useful.)
I think you two may be talking past each other a bit here. Bear in mind I am not a security expert, just a spirited hobbyist; I may be missing something. As stated in my digital resilience audit, I actually use both Tarsnap and restic for different use cases. That said:
Tarsnap's deduplication works on the archive level, not on the particular files etc within the archive. Someone can set up a write-only Tarsnap key and trust the deduplication to work. A compromised machine with a write-only Tarsnap key can't delete Tarsnap archive blobs, it can only keep writing new archive blobs to try to bleed your account dry (which, ironically, the low sync rate helps protect against - not a defense for it, just a funny coincidence).
restic by contrast does do its dedupe at the file level, and what's more it seems to handle its own locks within its own files. Upon starting a backup, I observe restic first creates a lock and uploads it to my S3 compatible backend - my general purpose backups actually use Backblaze B2, not AWS S3 proper, caveat emptor. Then restic later attempts to delete that lock and syncs that change too to my S3 backend. That would require a restic key to have both write access and some kind of delete access to the S3 backend, at a minimum, which is not ideal for ransomware protection.
Many S3 backends including B2 have some kind of bucket-level object lock which prevent the modification/deletion of objects within that bucket for, say, their first 30 days. But this doesn't save us from ransomware either, because restic's own synced lock gets that 30 day protection too.
I can see why one would think you can't get around this without restic itself having something to say about it. Gemini tells me that S3 proper does let you set delete permissions at a granular enough level that you can tell it to only allow delete on locks/, with something like
But, I have not tested this myself, and this isn't necessarily true across S3 compatible providers. I don't know how to get this level of granularity in Backblaze, for example, and that's unfortunate because B2 is about a quarter the cost of S3 for hot storage.The cleanest solution would probably be to have some way for restic to handle locks locally, so that locks never need to hit the S3 backend in the first place. I imagine restic's developers are already aware of that, so this seems likely to be a much harder problem to solve than it first appears. Another option may be to use a dedicated, restic-aware provider like BorgBase. It sounds like they handle their own disks, so they probably already have some kind of workaround in place for this. Of course, as others have mentioned, you may not get as many nines out of BB as you would out of one of the more established general-purpose providers.
P.S.: Thank you both immensely for this debate, it's helped me advance the state of my own understanding a little further.
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.
I found restic is a prety cool alternative. (No hosting though, I am sending restic backups to a private server/vps)
yep it's what i'm using right now
restic, and my own computers and storage, and the occasional rented device (VPS or similar, typically)
i find that the hassle of setting up my stuff is still preferable than having to worry about managing bills, subscriptions, and third parties just changing their policies
Same but with rustic because I found it used significantly less memory.
https://rustic.cli.rs/
Is it stable? I've been using restic for a while, and I'm interested in rustic, but I have no idea how stable it is overall. Obviously it's still in beta so I won't use it in prod but curious what others experiences have been like.
You might want to check this out https://github.com/garethgeorge/backrest
I'd say its stable. It's one of those projects that's in perennial beta.
+1 for restic
Restic + rclone is a very nice combo. Works really well.
Curious why use both? I use restic directly with B2 backblaze, whats rclone doing for you here?
I use restic + rclone to back up to onedrive, where I have 1TB space included with my subscription.
My main backups are on rsync.net, though.
I also switched away from Tarsnap because I needed to restore my personal PDF collection of like 20GB once and my throughput was like 100Kb/s, maybe less. It has been a problem for at least a decade, with no fix in sight.
I'm carefully monitoring plakar in this space, wondering if anyone has experience with it and could share?
It can be whatever it wants I am not paying $25 to store 100GB. I used to use Tarsnap a decade or so ago but pricing makes no sense at all nowadays.
Looks like much for both Colin and us could be solved moving this away from AWS
The pricing isn’t due to AWS. Even if you used standard S3 and paid for data retrieval for your entire backup every single month, tarsnap is over 3x the price of just using S3 yourself. The markup on tarsnap is wild.
Using something like restic or borgbackup+rclone is pretty much the same experience as tarsnap but a fraction of the price.
Yeah that pricing is crazy for something without any of the security that comes with using a BigCo. I've bounced off it in the past as soon as I got to their cutesy pricing model but I just played with the calculator linked here to model my needs -- three thousand USD a year for 1Tb of cold storage??
I appreciate you using the calculator! It's at [1] for anyone who wants to futz around with it.
$3000 per TB-year is accurate to my knowledge, and yes, it is at least one, and probably two, orders of magnitude what you can get with more general purpose systems. Backblaze B2 is $72 per TB-year; AWS Glacier is $12 per TB-year I believe; purchasing two 20 TB Seagate drives for $300 apiece, mirroring them, and replacing them every 3 years gives you about $10 per TB-year (potentially - most of us don't have 20 TB to back up in our personal lives). Those are the best prices I've been able to find with some looking [2].
To me, when I was building out the digital resiliency audit, the pricing and model just seemed to tell me that tarsnap was for very specific kinds of critical data backups, and was not a great fit for general purpose stuff. Like a lot of other people here I also have a general-purpose restic based 3-2-1 backup going for the ~150 GB in /home I back up. [3] My use of tarsnap is partly a cheap hedge for the handful of bytes of data I genuinely cannot afford to lose against issues with restic, Backblaze B2, systemd, etc.
[1]: https://hiandrewquinn.github.io/tarsnap-calculator/
[2]: https://andrew-quinn.me/digital-resiliency-2025/#postscript-...
[3]: https://andrew-quinn.me/digital-resiliency-2025/#general-bac...
Tarsnap has always been expensive. More than a decade ago (April 2014, to be precise), @patio11 suggested that tarsnap should increase its pricing. [1] Here’s the HN thread on that post. [2]
All the granular calculations (picodollars) on storage used plus time are fine. But tarsnap was always very expensive for larger amounts of data, especially data that cannot be well deduplicated.
[1]: https://www.kalzumeus.com/2014/04/03/fantasy-tarsnap/
[2]: https://news.ycombinator.com/item?id=7523953
Do they charge for actual bandwidth as well? Seems like it. From tarsnap.com:
> Tarsnap uses a prepaid model based on actual usage: Storage: 250 picodollars / byte-month of encoded data ($0.25 / GB-month) Bandwidth: 250 picodollars / byte of encoded data ($0.25 / GB)
OP's cost estimator tells me it would cost a cool $250 per month to keep a terabyte of data backed up in Tarsnap. The same amount costs me $8.25 per month with Backblaze. That's not very cozy!
OP here, thanks for using the cost estimator! [1] I'm glad you got some use out of it.
I use Backblaze B2 myself for most of my general purpose backup needs. It's actually $6/month, I believe.
Tarsnap fills but one niche in my overall system. It's a very important niche for which I haven't found any other providers who do anything similar (keyfiles, prepaid, borderline anonymous etc), but it's not where I store the vast majority of my stuff.
[1]: https://hiandrewquinn.github.io/tarsnap-calculator/
I just don't really understand what the niche is. If you have a tiny bit of data that you want to keep backed up and rarely access, you can encrypt it with any number of easy command-line or GUI tools and upload it to Google Drive, Dropbox, or anywhere else with a free tier. If it's securely encrypted, there's no reason to care that the storage provider knows who you are. Tarsnap definitely has nerd appeal, but I can't think of a real problem that it actually solves.
I readily admit I'm a nerd about this stuff, and this is primarily a hobby of mine. I am explicitly not 80/20'ing this because it's fun. [1]
One use case: I don't like the idea of having any accounts at all which I log into without the aid of a password manager. That creates a bootstrapping problem - how am I supposed to log into Google Drive to get my Google Drive password? A prepaid keyfile-based model is one particularly robust way of solving this. You stick your e.g. 100 kB password database in there, print out and shred the keyfile, stick the printout in a fireproof safe, and be virtually certain that whatever you put in Tarsnap has been untouched however many years you come back to it later. Print it on archival paper with some silica gel packets and it might survive for millennia in your weird subterranean vampire family castle.
"The business won't survive that long." I'm not so sure. Its ongoing costs appear minimal, and it generates eye watering amounts of float. $5 paid today is >$200 fifty years from now when compounded at 8% real interest. That very fact makes it much more likely that Tarsnap actually will survive for those 50 years, which should make us more likely to trust it, which... You see where this is going. This is one of those things where aggressively pricing too close to the bare metal costs might actually be a bad thing to a very important subset of users. One might even make the argument that, if the margins are as good as I'm supposing they are, then depending on the goals of the founder, Tarsnap is more likely to outlive S3 than S3 Tarsnap.
But again: Primarily a hobby.
[1]: https://andrew-quinn.me/digital-resiliency-2025/
Google supports printable 2fa codes
https://support.google.com/accounts/answer/1187538?sjid=3244...
print those and password, stick the printout in a fireproof safe
You're on the right path! Alas, I am a heretic and think recovery codes under my approach may cause more problems than they solve. [1]
Caution may be justified when it comes to doing this for something with as wide a surface area as a Google account. For me, if I'm going to have to compromise on 2FA somewhere anyway, I might as well go full hog and get an honest to goodness keyfile.
[1]: https://andrew-quinn.me/digital-resiliency-2025/#wait-what-a...
>but I can't think of a real problem that it actually solves.
Maybe it's good for storing stuff that's illegal to possess?
I actually do that. I have two folders one synced up to Dropbox and another to iCloud and they are encrypted with Cryptomator. But I back up the mounted folders i.e data to tarnsap. Besides those encrypted files (fragments?) of Cryptonator were messed up by both iCloud and Dropbox over the last few years. Gratned it could be Restic and Borg (I use these two as well for larger data sets), but for very small data tarsnap has woked well for me and prices are tiny. For a larger data set, I won't pick tarsnap.
If there's an simple but "solid" GUI backup tool with (true) PAYG I'd migrate away from Tarsnap, but there isn't one.
I used tarsnap for years, but as my data got bigger and I really wanted to have multipe offsite backups with different providers, I moved to restic. I loved tarsnap - it's a great product. But restic feels very similar but you can backup to your local HD, a remote HD, or "the cloud" and everything is the same CLI commands.
What provider(s) are you using?
I use borgbase (they support restic) - backblaze with their s3 backend, and my own servers. So server A will copy to server B and vis-versa every ~10 minutes snapshot for quick/easy restoration should it be necessary, then nightly backups to borgbase/backblaze.
As several said, Restic does the same for free (bring your own storage). Tarsnap makes no sense, it’s 50-100X more expensive than alternatives.
And Restic is good quality software.
The interface is nice but it is excruciatingly slow at restores. I had to switch to borg, which has an extremely similar feature set but performs much better (and you can bring your own hardware).
Seriously. If you are considering Tarsnap, or use it but have never tested a restore, don't hand wave this comment away.
You might be tempted to think: it's a popular service, it can't be that bad.
But, it really can be, and if you've not tried it yourself, you'll only find out when you need it. Which could be way too late.
I'm really surprised to hear that the slow restore times from tarsnap are still as big a problem now as they were a decade ago when I last used it. I absolutely loved the interface and the security model, and I was willing to pay at the (very) premium price point, but it was just too impractical trying to restore anything from it at the speeds I could achieve. (If I remember right, there was some problem with the design which meant normal latency between the client and the server tanked throughput to crazily low levels.)
Tarsnap seems very expensive.
I'm backing up about 8TiB of data nightly using BorgBackup[0] + InterServer[1] and pay $240/yr.
This gives me differential encrypted rotating backups that are 100% mine and do not lock me into any specific storage vendor.
[0] https://borgbackup.readthedocs.io/en/stable/
[1] https://www.interserver.net/storage/
Coziness comes at a cost. $250/TB/month is very expensive. Dropbox charges $5/TB/m, Hetzner $4 (traffic included).
I really wanted to like Tarsnap and gave it a good hard look for my backup needs. Ultimately my problem was that there's no way for me to gauge how much the service will cost me. Going just by the amount of data in my home dir, it would be cost prohibitive to upload to Tarsnap. The site does assure me that thanks to compression and deduplication, the actual cost will be far less than I might estimate, which is great! But also, as far as I can tell there's no way to have the client give me an estimate of "here's how much data you actually have once the secret sauce is applied". So while the dedup and compression might make the costs far more reasonable, I won't actually know until I pay to store some data. Which means I might find that suddenly I owe Colin a lot of money if the size savings aren't very big due to my data not being very amenable to those measures. That's not a risk I'm willing to take, so ultimately I pursued other options.
tarsnap --dry-run --no-default-config --print-stats --humanize-numbers -c /MY/DATADIR
will tell you the compressed size of your deduplicated data, which gives you the upload cost and first-month cost. 4GB of files usually works out to 3GB of dedup/compressed archive data for most people, less for people with many similar files.
Thank you very much for the info! I'm glad to have been wrong, and that there is a way to do this.
50x more expensive than a hard drive feels like a lot.
It depends on what you're after and what you're using it for. I broke down the costs I forecast for myself over the next decade at https://andrew-quinn.me/digital-resiliency-2025/#postscript-... and found tarsnap is unlikely to cost me more than 50 cents for my usecase. Backblaze B2 will cost me about $70-80 over the next 10 years, but it has many orders of magnitude more data to back up.
The cheapest I can find for a consumer buying e.g. 20TB Seagate hard drives and rotating them every 3 years or so is about $5 per TB-year, without mirroring. So if raw storage cost optimization is what you're after that's what I'd go for to start. Even AWS Glacier doesn't come close to that, although you do get other things with it.
it's expensive but it doesn't have a monthly base cost, doesn't require you to run a server etc.
through you want at least one backup of yours to be off site, and your want your backups robust, so comparing hard drive cost seem strange as if you run the backup server yourself you need a decent raid and for the offline backup you need to compare with idk. S3 storage cost or similar
it's still more expensive but if you only need to backup some folders of documents or similar it might anyway be the simpler and cheaper solution
if you want to backup huge photo/video/vm image collections it probably isn't the best choice for you
but if you need to backup you photo
A hard drive under the bed is not the only alternative to tarsnap, you can use any of its numerous competitors that are also maintained by professionals, whose whole business is also running a backup service. Say rsync.net or borgbase, which are at least 10× cheaper than tarsnap last time I compared them, and can be used with restic or borg which are much faster at restoring even relatively small amounts data (forget if we're talking terabytes, it's "weeks" vs "your link speed").
I think tarsnap was a good service about 20 years ago when it had little competition, but using it now makes very little sense IMHO. You can donate to its awesome FreeBSD maintainer, or to FreeBSD, directly.
> A hard drive under the bed is not the only alternative to tarsnap
Also you can back up to the hard drive under your friend's bed, and they can back up to the hard drive under your bed.
If you're even slightly technical, or have a friend who is, I'd recommend both of you buying the cheapest Kirkwood NASes you can find on ebay, throwing Debian on them, and becoming each other's backup buddies.
https://forum.doozan.com/read.php?2,12096
That's what I do! I have a couple of friends from college and we back up to each other over a VPN. It's a very nice solution to the off-site backup need.
> Say rsync.net or borgbase
Borgbase had a week long (IIRC) outage due to a failed attempt to add new drives to an array. As far as I know they never published a post-mortem on this and have never discussed how they're going to improve their disaster recovery so it can't happen again. It's difficult to recommend when they could leave you without working backups for an entire week.
you are comparing data storage to a backup solution, not the target market
For the price, there better be some plan for this service to exist in 10/100 years. With a bus factor of 2, that gives me little confidence.
I don't actually know what the bus factor for Tarsnap's infrastructure is. 2 is just the absolute lower bound from what I know of the company itself. It is in all likelihood much higher.
I can't read the founder's mind, but if I were them I would probably have some Kongō Gumi style designs on making it a 1000-year company just because that's a fun intellectual exercise. [1]
[1]: https://www.tofugu.com/japan/oldest-businesses-in-japan/
Switched away from Tarsnap to BorgBase - https://www.borgbase.com/
This sounds cool, but the other comments here are concerning. I've been considring Hetzner's Storage Box, as it's cheap and I could use just about anything to backup my stuff – although I prefer restic.
https://www.hetzner.com/storage/storage-box/
Storage Box with Borg backup can be setup to work almost identically to tarsnap.
The only real security feature missing is write-only access to the repository (Borg backup in theory supports it, but in practice it's impossible to use it in a way that prevents a compromised host from deleting it's backups - like tarsnap does).
In theory it is less reliable than tarsnap (AWS S3 compared to a single copy on a Hetzner's drive).
Storage Box is significantly cheaper for any kind of real-life backup sizes in my experience.
Borg requires more work to setup and configure compared to tarsnap. There's typically some scripting involved that's unique to your setup and I found that I had more documentation to study before I understood how to use Borg correctly.
A know a few people that have very low opinion of Borg's code quality and stay away from it because of it (I haven't studied it first hand)
You could activate snapshots on your Sotrage Box and don't give your Borg user access to it.
Does anyone know how it compares to restic or duplicate?
I use restic. Restic offers everything advertised on the tarsnap website (deduplicated snapshots, e2e encryption). I pay $6 per terabyte per month using backblaze's cloud object storage. Wasabi offers 1TB at $7/mo. S3 costs $26/mo, but glacier is only $3.6/mo.
Storing one terabyte of data in tarsnap costs $250 per month.
Basically the same service, but much more expensive.
why would someone do this instead uploading the encrypted chunks/updates to gdrive or anywhere else?
Tarsnap's model is an ideal fit for a very small subset of the data I'm interested in safeguarding for the future. https://andrew-quinn.me/digital-resiliency-2025/ goes into it in a lot more detail.
If you're interested in safeguarding data for the future, then I don't think the model of “my backup immediately disappears once the account runs out of money” gives me anything resembling a cozy feeling at all.
That's actually one of my favorite features. That should never happen under the limited circumstances I use it for. If something goes so wrong that my account actually runs out of money before I notice, then I far prefer the default to be "intruder alert, intruder alert, wipe everything". There's a reason it's marketed as backups for the truly paranoid.
Then why bother backing up at all? Buy some gasoline and set your laptop on fire, you'll never get more secure than that.
For me, personally? I do it for kicks. But in general, there do exist many data loads in the world which are valuable to the holder, valuable enough to be worth the low cost of a backup, up until time T in the future. After T, however, they become more of a liability than an asset to hold. A self-destructing backup model is the obvious fit for such situations. Both the positive-sum and the negative-sum periods need to be considered to truly safeguard your data properly.
probably rsync.net or zfs.rent are more cozy
OP's has a link typo in tarsnap cost eestimator.
OP, link seems to work fine for me.
the link in the title of the estimator page. it is tarsnas.com/utility.html instead of tarsnap.com/utility.html
Fixed, thank you!
gzip + ccrypt -> thumb drive
Also cozy if your data fits. No monthly fee, just the cost of new/recycled thumbies
I love thumb drives, but Tarsnap is cheaper than the expected 10 year lifetime of a fresh and well maintained thumb drive for the kind of data I hold in there by about a factor of 20 (50 cents vs $10).
It also doesn't require a UL Class 125 fireproofed safe to survive a house fire, but that's splitting hairs and getting into hobbyist territory.
tarsnap is not cheaper than anything
I've been using Tarsnap for almost a decade for a small, but very important, personal data subset.
Tarsnap is very resilient; it doesn't do a lot, but what it does is solid. The mailing list is helpful, and you can reach out to its creators directly for prompt, useful responses if that is something you don't want on the mailing list (where names and email addresses are in the clear; use marc.info to search in it).
But if you are trying to start with Tarsnap, you should note a few things from the beginning:
- If you are looking for a completely (or even almost) frictionless backup experience - this is not it. Also, it doesn't have tons of features - which might be a good thing, but you should know and accept it.
- If you're used to tools like Backblaze, CrashPlan, Restic, or Borg, the limited feature set might frustrate you.
- Knowing this in advance will help you set expectations within its feature set. The doc/man pages are great resources once you actually read it.
- It has some quirks (may or may not be bugs) that require tinkering with your settings, env etc. Getting your hands dirty with sample data first is a great way to know Tarsnap.
- Set up your logs and scripts such that you can know/debug things later.
- Naming of your archives is important.
- You'll need at least two keys: a master key with read, write, and delete access on your archives/Tarnsap storage, and a un-passphrased regular key with only "write" permission for backups. Keep both safe, especially the master key. There's "nuke" as well…
- I used its GUI for the longest time but would absolutely not recommend it. It hides a lot, which might come back to bite you, and is not the most polished tool of all. Its last release was 7 years ago.
OP says:
> … If you use it solely to back up the few megabytes of “crown jewels” data we all have lying around"
and I actually use Tarsnap exclusively for my "crown jewels," which are in the early three digit MBs.
- So, unlike what many say, I do believe it is costly for today's storage/bw prices, especially if your data isn't very compressible. Tarsnap's compression is great, but not magic. However, i doesn't cost an exponential bomb either. Killer de-dupe though.
- You must have a plan for what and how much you want to back up, and the expected growth of that data.
- It is definitely not a "fire and forget" tool (and you should never forget your backups anyway).
I was frustrated with it until I gave up on the GUI, embraced the CLI/cron, reduced the amount of data being backed up and excluded (using copy and delete) some data being stored, and accepted what it can't do. Which is not really great but that's what it is.
Glaring omissions, IMHO: very few maintenance features (the scripts listed are not easy to work with), (almost?) no way of knowing what file changed in a certain archive, slow restores (may matter for a bigger data set), and the lack of an updated, polished GUI tool which I think is very important for personal data backup.
My request to cperciva would be: please consider this - while it's inspired by tar and stays close to it, it's also a cloud backup tool. Treating it a bit more like a modern cloud backup tool could be useful. Just my two cents.