'Best' cloud storage backend in 2025

[Dinsdale]

Hi,

I am pleasantly surprised with the choice of cloud backends, but that also makes it hard to choose. From what I have read in the older posts here so far, it is not very wise to go with cloud drives like OneDrive, Google Drive etc. I also read some negative comments on iDrive e2, but those comments were (also) quite dated. B2 is ok. AWS S3 only supports standard which is quite pricy, but that comment also is quite dated.

So, for around 3 to 4TB of data what would you suggest to use as a cloud backend and why?

FYI, I am currently on Crashplan so speed is not an issue

Thanks for your input.

[saspus]

There is no one-size-fits-all really.

Depends on what data you backup (few large or many small files, with corresponding choice of chunk size), how often and how much of that data changes, how much do you expect to restore annually, whether performance is important, etc.

@Dinsdale

it is not very wise to go with cloud drives like OneDrive, Google Drive etc.

Fully agree.

@Dinsdale

I also read some negative comments on iDrive e2, but those comments were (also) quite dated

The company did not change its business model. Their incentives are misaligned with that of their users. All critique is still applies. It’s in the race to the bottom. Don’t use such companies.

@Dinsdale

B2 is ok

Debatable. I would not trust them either based on past history. Also see previous comment, it applies to them as well.

@Dinsdale

AWS S3 only supports standard

This is not accurate. Duplicacy supports all storage tiers except glacier subsets that require thawing. For example, GlacierInstant Retrieval work — but makes no financial sense. You can use Google archive tier — but need to be careful with minimum retention charge.

That’s why it’s hard to give a blanket recommendation without knowing specifics.

If I had to give a default recommendation: for a reasonably priced, with good track record, excellent performance, geo-redundancy, scalability, and right priorities alignment hot/nearline storage for active backup today I would (and did) pick STORJ. Depending on your network setup — native integration, or if upstream or CPU performance is an issue — their S3 gateway.

@Dinsdale

I am currently on Crashplan

Whoa. Did not realize they are still around. That’s been a while!

[Meowcat285]

Personally I’ve found Hetzner’s storage boxes to be pretty good in terms of pricing, especially since it’s a fixed price. The downside is that I’m in the US and the storage boxes are in Europe (Germany or Finland) and as a result I only get about 100 mbit/s both ways.

[Dinsdale]

@saspus My backup reports from Carshplan go back to 2010, but I probably have it longer than that. The other day I decided I wanted a SATA SSD for my backup. I decided that instead of copying the current backup archive I wanted to create a new archive. No problem to start that up in Crashplan. Just add a Destination, tell them what the sources are and off you go… at a whopping speed of at best 10MB/sec, but more likely 5MB/sec Which is pretty amazing when you make a backup from one SSD to another. I logged a ticket with Crashplan over a month ago and they are still ‘analyzing’ and telling me that 20Mbps (that’s megabit) is ‘fairly fast’.

My first attempt was iDrive as I had read a good review on Macworld. Pretty fast both local and cloud backup. But when I wanted to test their restore function with my local backup I found out that iDrive doesn’t support versions on Mac, so you can only restore from your last backup. When I asked about it they called versioning an interesting feature request that would pass on to development for review. Exit iDrive…

[Dinsdale]

Interesting solution and fortunately I am based in Europe. Are you using SFTP to access? How does the connection time fee work out for you? Is that only being charged when you backup/restore etc.?

[Meowcat285]

I’m using SFTP, and there’s no fee for bandwidth

[Meowcat285]

Little update to this, I managed to overcome the 100 mbit/s issue by using WebDAV instead of SFTP and setting up a VPN server on a cloud server in the same region and using that as a relay to the storage box. I’m able to get about 50 MB/s that way at peak

[saspus]

That’s a pretty attractive offer, if you manage to use amount of storage close to the allocation, which is very hard to do. Generally, I’d avoid providers that charge fixed fee regardless of whether you use that space or not.

[Meowcat285]

I am using almost all of it, so that’s proven quite nice

[fronesis]

Earlier this year I started a thread with almost the exact same title, so there might be some useful info there if folks are curious:

Best Storage Backend in 2025

Updating this thread only because Storj is recommended in it, and today Storj changed their pricing structure to include a $5 minimum monthly charge. For anyone without a lot of data to store, this makes them dramatically more expensive. For anyone with over 1.25TB, it doesn’t really change anything.

I ended up going with GCS using their autoclass settings. The advantages of this choice is that you get a high quality storage provider (google), you get access to “archive”-level (or cold storage) costs, and you do not have to worry about any settings to make this work. I backup to hot storage, and after it sits for a while, google just moves it over and charges more less.

I backed up around 100Gb and I’m now in month 4. Currently I have about 2Gb in regional, 5Gb in nearline, and 93Gb in coldline.

This translates to rough costs as follows:

$2 for the first month
$1 for the 2nd and 3rd months
$0.60–0.65 or so for months 4 through 12 (where I am now)
$0.15–0.25 per month after that (my estimate)

Data transfer out of google cloud is $0.12/Gb, so a restore would cost me about $12 (there are no “retrieval” fees, but these “transfer” fees apply).

There are cheaper options, and if you are routinely uploading a ton of data, this might not be ideal. But for my situation it was a nice solution.

[saspus]

Does it mean that paying more for newer, potentially transient data, overweights the 365 day minimum retention retention fee? (Meaning why auto class and not direct to archive?)

[fronesis]

Any data retrieval at all costs $0.05/Gb/month, and GCS seems to define “retrieval” broadly:

A retrieval fee applies when you read, copy, move, or rewrite object data or metadata

My best guess is that if you set up a new bucket on GCS and designated it as archive class, such that ALL of your interacts with GCS are with that archive class bucket, then each month you’d have to pay fees for interacting with that data. You would also certainly have to move it out of archive before trying to restore. I wasn’t sure exactly how all those costs would add up, and I’d read horror stories about “gotchas” for people trying to use cold storage.

I don’t know for sure how it would all work out, and what kind of fees would hit me if I had gone with just an archive class bucket.

[saspus]

Ok. Makes sense.

There are no gotchas, all fees are spelled out on pricing page. But generally, if you use archival storage, the expectation is that you plan to never restore, so cost of retrieving data should be irrelevant.

Except with duplicacy you can’t separate working hot set from the rest of the data: metadata chunks are guaranteed egress, if you delete local cache.

So until that is fixed — I would not recommend using archival storage at all.

It should be pretty easy for duplicacy to separate metadat into a separate folder, so we could set storage class based on prefix.

No idea why is this not done years later. Perhaps nobody really wants it.

Fairly recent discussion: Low cost / Archival storage discussion - #5 by saspus

[fronesis]

@saspus

generally, if you use archival storage, the expectation is that you plan to never restore, so cost of retrieving data should be irrelevant.

Yep, that was my approach going in. I never plan to restore. That said, this is a worst-case scenario backup, and I find it helpful to know ahead of time what a restore could cost should I ever need to use it.

Except with duplicacy you can’t separate working hot set from the rest of the data: metadata chunks are guaranteed egress, if you delete local cache.

Yes, exactly. This is why I didn’t go with a straight archival class bucket. Instead, as an experiment I turned on autoclass so that I could then watch and learn – and see how much data needs to stay in hot storage. The advantage is that rather than paying fees for egress out of hot storage, I just pay a small fee for data that stays in hot storage.

So until that is fixed — I would not recommend using archival storage at all.

Yes, exactly!
This is why I’m doing autoclass. I’m 99% certain (from reading beforehand, and now watching my data) that I’ll pay LESS with autoclass than I would with just choosing hot storage. For me autoclass allows me to say: well, I’m just gonna do hot storage, but if google wants to move stuff to cheaper storage tiers behind the scenes, and save me money, great.

It should be pretty easy for duplicacy to separate metadat into a separate folder, so we could set storage class based on prefix.

Agree, 100%! If duplicacy ever implemented this, I’d change over to a strictly archival bucket. (And if restic implements it - it’s experimental now - then I’ll switch over to restic.)

No idea why is this not done years later. Perhaps nobody really wants it.

I do!!! And I’d think a lot of others would as well.

Fairly recent discussion: Low cost / Archival storage discussion - #5 by saspus

Oh sure, I read that very carefully before embarking on this experiment.

[facboy]

i probably mentioned this in the original thread, but my bills on GCS have stabilized around £1.10 per month for 565G.

[Dinsdale]

Sounds like a really interesting option especially since for me it is a DR copy as well. Do you have any influence on how fast data is migrated to cheaper tiers, or is it really Autoclass?

[fronesis]

@Dinsdale

Do you have any influence on how fast data is migrated to cheaper tiers, or is it really Autoclass?

It’s completely automatic, so out of the user’s control. In my experience the migration happens right on the clock: at 30 days it moved to nearline, at 90 it moved to coldline, and I expect it to go archive at 365 days.

In my duplicacy bucket I currently have a total of 50Gb: 1Gb is still in hot storage (regional), 2Gb is in nearline (that accurately reflects a couple of gigs of NEW data in my source folder from 6 weeks ago), and 47Gb is in coldline.

I have 100Gb total and my bill for July was 65 cents. It should be under 50 cents in August. The next big drop for me won’t come until spring.

[Droolio]

I wonder how pruning works with this setup? Does it have to unfreeze objects in order to delete?

[fronesis]

Good question. I assume so, but I don’t know. At $0.0012/Gb, I assume it’s cheaper to just leave the data there than to pay to delete it. So I’m not running any prunes, just checks.

[Droolio]

Hmm you’re probably right. I asked Mr Gippty, apparently:

No retrieval (egress) is required to delete them, so there is no unfreezing process or retrieval cost just for deletion.

But:

Early deletion fees apply if you delete an object before the minimum storage duration for its tier:

• Nearline: 30 days
• Coldline: 90 days
• Archive: 365 days

So you could technically do it, but you need to be careful not to prune anything in those windows.

Personally, I’d wanna combine this with a local backup storage. This way, you can copy from GCS only the necessary chunks to repair a broken local storage.

Failing that, you could initialise a local storage and ‘pre-seed’ chunks from your source data, before copying from GCS to local to fill in the gaps. That’d be a pretty good strategy to keep the restore costs down IMO.