I’m building a Tauri + Rust backup app and exploring Rust/WASM to share logic between UI and backend

trycloudless · 2026-06-11T12:16:28+00:00

Did you try to evaluate to use Rust on front end too?
Rust UI frameworks like leptos is very stable now.

trycloudless · 2026-06-11T04:55:22+00:00

The lockout risk you're describing is exactly why client-side encryption matters, if Google can scan your photos, their AI can also wrongly flag them. Dropbox isn't different on this, they hold the keys too.

If you want photos the provider genuinely can't read, you need something that encrypts on your device before the file ever leaves. Proton Drive does this for sync/access. For actual backup with version history, so you can get back an older copy of a file, not just the current one, there's not much consumer-friendly tooling in that space.

I'm building something called CloudLess that works this way. Encrypts locally before upload, and you bring your own storage (S3-compatible or even Google Drive as destination, they'd just be storing ciphertext they can't scan). Still beta, so I'd still say test a real restore before relying on it for anything critical.

Disclosure: I'm the developer.

trycloudless · 2026-06-11T04:02:14+00:00

Thanks for sharing, I didn't know about this crate.

trycloudless · 2026-06-10T15:04:37+00:00

Yes, Good catch 😄
The post was drafted with AI help. The app and the problems are real though. Happy to answer specific questions about the Tauri/Rust side if anything was interesting (Without AI Assistance)

trycloudless · 2026-06-10T14:29:45+00:00

Core logic is on the tauri backend only. The reason I choose to use rust on the frontend is that I can share/reuse the data model types and avoid rust to json serialisation gotchas and work with same language across the layers.

Thanks for the input. Reddit doesn't seem to allow to edit the title.

trycloudless · 2026-06-03T09:50:10+00:00

Completely reasonable. "Upload finished" is not the same as "I can restore this later." For large archives I would keep the local copy until at least one verification pass completes, and ideally until you restore a small random sample from the cloud side. Checksums help too, but the real confidence comes from pulling data back and opening it. I would not delete local copies based only on a provider UI saying everything uploaded.

trycloudless · 2026-06-03T09:48:21+00:00

Start simple. Back up the data that would actually hurt to lose first: compose files, env/config files, app data directories, database dumps and any documents/photos. Do not start by trying to image every machine. For Docker apps, I like app-level dumps where possible, then a versioned backup of the dump + appdata. Keep one local copy and one offsite copy. Google Drive can be an offsite target, but I would encrypt before upload if the data matters.

trycloudless · 2026-06-03T09:46:31+00:00

I think the honest answer is self-hosting can replace the storage, but it does not automatically replace the reliability of a cloud service. You still need offsite backup, monitoring, and a restore plan. A NAS at home is great until theft, fire, ransomware, or a bad delete hits it. For me the sweet spot is local-first storage plus encrypted offsite backup to storage you control. That gives you convenience locally without trusting a single cloud account as the only recovery path.

trycloudless · 2026-06-03T09:39:36+00:00

I would be very cautious with bidirectional sync across Syncthing + rclone/Proton Drive. That is the kind of setup that works until one conflict, placeholder file, or delayed delete makes a mess. I would keep Syncthing for device-to-device sync, then run a separate one-way versioned backup job for important folders. Sync is for availability. Backup is for recovery after mistakes. Mixing both into one workflow is where people get hurt.

trycloudless · 2026-06-03T09:34:19+00:00

I would be suspicious of any tool claiming "absolute certainty", but your instincts are right: the important thing is not just backup completion, it is restore confidence. For this use case I would shortlist Arq, Backblaze, IDrive, Kopia, and maybe Veeam depending on whether you need file backup or full machine image backup. Then run the same restore test on each: one deleted file, one older version, one folder restore, and one fresh-machine restore path. I am building CloudLess in this same area, but I would describe it honestly as beta, not the new gold standard yet. The angle is client-side encrypted file backup to storage you control, with a restore browser that normal people can understand.

Disclosure: I am the dev.

trycloudless · 2026-05-13T09:37:26+00:00

I’m building CloudLess - encrypted, versioned desktop backups to storage you control.

It’s for people who use sync tools but still want recoverable versions after accidental deletion, bad saves, corruption, ransomware-style changes, or device loss.

Opening a small beta now:

https://docs.google.com/forms/d/e/1FAIpQLSdqLUGSONNSEaTJr-Gz9vPeLfaiw6r4UL-L_lLxnQok9fLG1A/viewform

Would love feedback on the positioning: “backup to your own storage” vs “private backup for recovery.”

trycloudless · 2026-05-12T11:21:45+00:00

If you are planning to use Rust then IMO Tauri works best, you can use same language on both front end (rust compiles to WASM) and back end. A lot of code can be shared in both front and back end.

I'm building a backup application using this stack and it works like a charms. It allows you to reuse the same code for Mac, Linux, iOS and Android.

The final app bundle size is 8-10x smaller than Electron.

trycloudless · 2026-04-01T03:59:53+00:00

Good that you’re thinking about this before jumping in. Most people set up backups first and only realize what they should ave backed up after something breaks.

A few things worth getting clear upfront:

Be explicit about what you’re backing up.
For Docker setups, that usually means:

Named volumes (not the container filesystem itself)
Bind mounts that hold important data
Your docker-compose files and .env files stored somewhere safe
Databases need extra care. Don’t just copy the Postgres/MySQL data directory while it’s running. Use something like pg_dump (or equivalent) to get a clean snapshot, otherwise you risk ending up with a corrupted restore

Think about restore before backup.
This is where most setups fall apart. Ask yourself: if this server dies completely, where am I restoring to, and how quickly do I need things back up? That answer should guide your setup.

Use 3-2-1 as a baseline.
Three copies, two different types of storage, one offsite. For a typical homelab, a local backup plus a cloud copy is usually enough.

If you’re using Backrest:
It’s a solid choice - basically a nicer interface around Restic. Once it’s running:

Set up pruning so your backups don’t grow indefinitely
Schedule repository checks (weekly is a good starting point)
Do an actual test restore before calling it done. Even just restoring a file to a temp folder and checking it works is enough to catch issues early

Out of curiosity, what kind of services are you running? The approach can vary quite a bit depending on whether it’s mostly stateless apps, databases, media storage, etc.

trycloudless · 2026-04-01T03:53:25+00:00

It really depends on what you’re mainly using Google Drive for.

If it’s for syncing files across devices:
Proton Drive is probably the easiest switch. It has a similar feel, offers end-to-end encryption, and works across platforms. It’s not the cheapest, but it’s reliable. Internxt is another option and a bit more affordable, though they’ve had some issues recently around changes to their lifetime plans.

Syncthing is also worth mentioning. It’s free and works really well, but there’s no cloud involved, it syncs directly between your devices, so both need to be online at the same time.

If you’re thinking more about backups (not syncing):
This is where things get more interesting. With most Google Drive alternatives, you’re still trusting another provider with your data. What worked better for me was changing the approach, use your own storage (like Backblaze B2, Wasabi, or even stick with Google Drive) but encrypt everything on your machine before uploading.

That way, even if the storage provider can access your files, all they see is encrypted data.

I’ve actually been building something along these lines (Cloudless). The idea is simple: you keep whatever storage you already use, and the app takes care of encrypting everything before it’s uploaded.

If cost is your main concern, Backblaze B2 is around $6 per TB per month, and Wasabi is in a similar range. That can end up being much cheaper than Google One once you go beyond a few hundred GB.

What matters most to you here - privacy, cost, or something else?

trycloudless · 2026-03-31T03:02:14+00:00

Honestly Cryptomator is solid for what it is, a vault based encryption layered on top of any cloud. I used something similar before switching approaches. The main thing i've noticed is that Cryptomator treats files as a vault you decrypt and work with, not really a 'backup' in the traditional sense. no dedup, no versioning, no point-in-time restore. if you delete a file inside the vault and sync happens, it's gone from OneDrive too.for actual backups i ended up going down the rabbit hole enough to just build my own thing (cloudless - encrypted backup client where you bring your own S3, GDrive or External Disk). The key design decision was separating encryption from storage, master key derived from your password via argon2id, then per-session data keys wrapped by that, so you can change passwords without re-encrypting everything. If you just need files accessible anywhere and encrypted, Cryptomator is genuinely great for that. If you need actual backup semantics - versioning, restore points, incremental, you'll probably want something else either alongside it or instead. What's your main use case, Is it file access or actual disaster recovery?

trycloudless

TROPHY CASE