We are considering off-site temporary backups for a customer using Mega.cz.
The testing has worked "ok" - except for the 2FA problem.
There are some posts in the forums about:
Are those "old news" or do these problems still exist with rclone uploads to mega.
If anyone has experience with these - please let us know.
I've tested Mega in the not-so-distant past (2022 or thereabouts), and here are my $0.02:
I would not trust their encryption at all. Use rclone's built-in encryption (on top of theirs, as I understand it can't be turned off) with a good passphrase, and keep your customer's data safe.
Haven't seen that in my tests. But probably not worse than with GoogleDrive (which also allows duplicate file/directory names): all it means is that once in a while you would have to run an rclone dedupe.
Worst of all for me was Mega's attitude -- even with fully encrypted data+names (so no possible piracy/copyright concerns), they started alleging AUP violations (without saying exactly what was being "violated", of course) and using that as an excuse for blocking my accounts (I had a union of a dozen or so of their free accounts that I was using for these tests), so I told them to go to hell and stopped my tests with them. Good riddance, I say.
Thanks for taking time to respond. We appreciate it.
We've done a bit of research -- so leaving this here as it may help others.
We have read many sites, links and forum posts on the web about Mega. It appears that the security bug was in 2022, and they have patched it. There is some debate online as to if they have patched everything that was identified in that security update.
Our duplicate file names concern can be addressed with Rclone's hashsum and dedupe commands .
We are down to looking at Mega and the Rclone sponsor iDrive e2 S3.
This is due to the amount of storage we need, the cost and the limited use cases.
iDrive e2 S3 does what we need without some of the unnecessary "extras" (bloatware) in Mega.
Mega has some nice user features for sharing links, and the mega-cmd tool for Linux -- but the chat, sync and other features are not needed. We just need a big box to put a lot of data and files in, and trust that when we decrypt it everything works. iDrive web interface and scripting with Rclone can get the job done. So will add a note after we decide.
Check out pCloud for link sharing and privacy/security. We have another customer using that and it works well.
Thanks again.
Quick follow-up for anyone else trying to figure out which storage provider to go with.
We decided to go with the Rclone sponsor iDrive e2 S3 storage for this use case. Cost, technical capabilities and egress "flexibility" were the main reasons. Our main use case is for long-term storage -- not file-sharing and link-sharing. Mega has a nice interface for those, but we have found pCloud to work well for that. So no reason to change it. We also wanted to support the team at Rclone by using the sponsor.
The separate Mega command tool (cli) works to save the original file timestamps on uploads - but adds in another tool to do something that Rclone already does very well. We found that Rclone does not currently save the original timestamp on Mega as noted in other threads here. That may change in the future with Mega's beta S4 storage., but we definitely are avoiding a beta system for our backups.
We tested with encrypted and unencrypted script scenarios - and found the workflow to be easiest with scripts using Rclone and crypt on iDrive. Once the buckets are setup, and the rclone configs are set to use encrypted and unencrypted buckets, it works as expected.
The iDrive service is fast for our region. We did notice some differences in speeds based on region selection for the buckets. So if you get into that area - test a few regions. Some that are a bit farther away geographically are actually consistently faster.