The Problem
Google Drive and OneDrive are sync tools, not backup tools. If you accidentally delete a folder, it’s gone everywhere. If ransomware encrypts your local files, the "mistake" propagates to the cloud immediately. There is no easy way to say: "Restore my entire Drive exactly as it looked on January 15th."
Why not just use Restic or Borg?
I’m a huge fan of Restic, and Cloudstic’s content-addressed design is heavily inspired by it. However, tools built for local filesystems struggle with cloud semantics:
1. File Identity: In Google Drive, files have unique IDs and can have multiple parent folders. They don't have a single canonical path.
2. Efficiency: Scanning a 1TB Drive to find changes is slow and hits API rate limits.
3. Structure: Restic’s tree structure mirrors a directory hierarchy. Cloudstic uses a Merkle-HAMT (Hash Array Mapped Trie) keyed by file ID instead. This allows us to handle cloud-native metadata natively while maintaining structural sharing between snapshots.
Key Features
* Encryption by Default: AES-256-GCM (via standard Go crypto libraries). You can recover via password or a BIP39 recovery phrase. Your storage provider (S3, B2, SFTP) sees only encrypted blobs.
* Cross-Source Deduplication: We use FastCDC (Content-Defined Chunking). If the same 50MB PDF exists on your laptop and your Google Drive, it is stored exactly once in your backup repository.
* Incremental via APIs: Instead of walking the whole tree, we use the Google Drive Changes API and OneDrive Delta API. It only fetches what has changed since your last snapshot.
* Crash-Safe & Immutable: All objects in the repository are append-only. An interrupted backup or a network drop leaves zero corruption.
* Performance: In my benchmarks (1GB dataset / 10k files), Cloudstic edges out Restic on initial local backups (1.2s vs 1.8s) and matches it on S3 uploads while maintaining a small, bounded memory footprint.
Quick Start
Cloudstic is a single static binary. You can point it at local disk, S3/R2/MinIO, Backblaze B2, or SFTP.
brew install cloudstic/tap/cloudstic
cloudstic init --backend s3 --bucket my-backups
cloudstic backup --source gdrive
cloudstic list-snapshots
cloudstic restore <snapshot-id> --to ./recovery
I’m also working on a managed version (https://cloudstic.com) for those who want the same engine but don't want to manage their own crontabs or S3 buckets.
The code is MIT Licensed. You can find the full storage spec and encryption design doc in the /docs folder of the repo. I’d love feedback on the HAMT implementation and the crypto design!