Cloudstic CLI – Encrypted Backups for Google Drive,

TL;DR

TL;DR: Cloudstic is an open-source Go CLI that deduplicates and encrypts backups from Google Drive, OneDrive, and local directories, storing them to S3-compatible backends (including R2), with point-in-time restore and retention policies.

Source and Accuracy Notes

• Project page: cloudstic.com — product site
• Source repository: github.com/Cloudstic/cli — verified README, v1.14.0
• License: MIT — verified via GitHub API license.spdx_id
• HN launch thread: news.ycombinator.com/item?id=44725306 — Show HN launch

What Is Cloudstic?

Cloudstic is a content-addressable, encrypted backup CLI written in Go. It backs up three source types — Google Drive, Microsoft OneDrive, and local directories — and stores the results in an encrypted, deduplicated repository on any S3-compatible backend (including Cloudflare R2, Backblaze B2, MinIO, or plain local filesystem).

The key differentiator is client-side encryption with deduplication: identical file chunks stored across multiple sources or machines are stored only once. The README describes it as:

Content-addressable, encrypted backup tool for Google Drive, OneDrive, and local files.

Supported Sources

Source	Flag	Notes
Local directory	-source local	Auto-detects portable drives by GPT partition UUID
Google Drive	-source gdrive	Full rescan of My Drive or Shared Drives
Google Drive Changes	-source gdrive-changes	Incremental via Changes API (recommended)
OneDrive	-source onedrive	Full scan of OneDrive account
OneDrive Changes	-source onedrive-changes	Incremental via Delta API (recommended)

Supported Backends

Local filesystem, Amazon S3 (and compatibles like Cloudflare R2, MinIO), and Backblaze B2. Prefix-based namespacing lets multiple repositories share a single bucket.

Security Model

• AES-256-GCM encryption by default
• Password, platform key, or recovery key slot unlocking
• Key slots allow credential rotation without re-encrypting all data
• 24-word recovery key generation (cloudstic key add-recovery)
• All encryption happens client-side before upload

Setup Workflow

Step 1: Install

# macOS / Linux via Homebrew
brew install cloudstic/tap/cloudstic

# Windows via winget
winget install Cloudstic.CLI

# Go
go install github.com/cloudstic/cli/cmd/cloudstic@latest

# Curl installer (macOS / Linux)
curl -fsSL https://raw.githubusercontent.com/Cloudstic/cli/main/scripts/install.sh | sh
```bash

Download binary releases for other platforms from [github.com/Cloudstic/cli/releases](https://github.com/Cloudstic/cli/releases).

### Step 2: Initialize a Repository

```bash
cloudstic init
```bash

This creates an encrypted repository. It prompts for a password interactively, generates a master encryption key, and wraps it into a key slot protected by your credentials.

### Step 3: Run a Backup

```bash
# Local directory
cloudstic backup -source local:~/Documents

# Google Drive (opens browser for OAuth on first run)
cloudstic backup -source gdrive-changes

# OneDrive
cloudstic backup -source onedrive-changes

# Portable drive (auto-detected by partition UUID)
cloudstic backup -source local:/Volumes/MyUSB

# Dry run preview
cloudstic backup -source local:~/Documents -dry-run
```bash

Google Drive and OneDrive work out of the box — Cloudstic opens your browser for OAuth authorization on first run and caches the token locally.

### Step 4: List Snapshots and Restore

```bash
# List all snapshots
cloudstic list

# Restore latest snapshot to a zip file
cloudstic restore

# Preview what changed between two snapshots
cloudstic diff <snapshot-a> <snapshot-b>
```bash

## How the Backup Internals Work

Cloudstic's architecture layers storage concerns for flexibility. From the docs:

> `CompressedStore → EncryptedStore → MeteredStore → [PackStore] → KeyCacheStore → Backend`

All objects are content-addressed with keys like `chunk/<hash>`, `content/<hash>`, `filemeta/<hash>`, and `snapshot/<hash>`. The process per backup:

1. **Scan** source files and chunk them using FastCDC
2. **Hash** each chunk with SHA-256
3. **Deduplicate** — skip chunks already present in the repository
4. **Compress** remaining chunks with zstd
5. **Encrypt** with AES-256-GCM
6. **Upload** only new chunks to the backend
7. **Index** file metadata in a Hash Array Mapped Trie (HAMT) structure for immutable snapshots

This means the first backup uploads everything; subsequent backups only send changed chunks. Google Drive and OneDrive incremental sources use change delta APIs for even faster subsequent runs.

## Retention Policies

Cloudstic ships with flexible retention rules. Examples from the docs:

```bash
# Keep last 7 daily snapshots
cloudstic forget --policy "keep-last:7,daily"

# Keep weekly for 4 weeks, monthly for 6 months
cloudstic forget --policy "keep-last:4,weekly;keep-last:6,monthly"

Policies can be applied per source, tag, or account for granular control.

Practical Evaluation Checklist

• Encryption: AES-256-GCM, client-side, all data encrypted before upload
• Deduplication: Content-addressable — identical chunks stored once across all sources
• Portability: Portable drives identified by GPT partition UUID; back up the same physical drive from any machine or mount point (macOS, Linux, Windows)
• Backend flexibility: S3-compatible — store where you want (R2, B2, MinIO, self-hosted)
• Incremental: First backup is full; subsequent backups only send changed chunks
• Restore granularity: Point-in-time restore of any file from any snapshot
• Key recovery: 24-word recovery key per repository slot
• Auth: OAuth-based for cloud sources; token cached locally after first browser flow

Security Notes

• Client-side encryption — the backend never sees plaintext
• No default key escrow — losing your password means losing access; the recovery key is the only fallback
• Key slot design supports credential rotation without full re-encryption
• Repository locking coordinates concurrent access via distributed locks stored in the repository itself (prevents corruption from crashed processes with cloudstic break-lock)

FAQ

Q: How does Cloudstic handle the encryption key? A: On cloudstic init, a master encryption key is generated and wrapped into a key slot protected by your password. The slot design allows multiple credentials (password, platform key, recovery key) to unlock the same repository. Changing the password re-wraps the master key without re-encrypting all stored data.

Q: Can I use Cloudstic with Cloudflare R2? A: Yes. R2 exposes an S3-compatible API. Point Cloudstic at your R2 bucket URL and credentials the same way you would for AWS S3.

Q: What happens if the backup is interrupted? A: Cloudstic uses repository locking. If a process crashes mid-backup, the lock is left behind and can be cleared with cloudstic break-lock. Repository integrity can be verified with cloudstic check.

Q: Does it support Google Workspace Shared Drives? A: Yes. The -source gdrive and -source gdrive-changes flags cover both My Drive and Shared Drives.

Q: Is there a way to preview what a backup would do before running it? A: Yes. Add the -dry-run flag to any backup command to see what would be uploaded without making any changes.

Conclusion

Cloudstic fills a specific niche: open-source, client-side encrypted, deduplicated backups for mixed environments (local files, Google Drive, OneDrive) with flexible S3-compatible storage. Its content-addressable architecture means backing up multiple machines or cloud accounts to the same repository is efficient — identical chunks are stored once.

The tool is actively maintained (v1.14.0 as of July 2026), MIT-licensed, and the codebase is at github.com/Cloudstic/cli. If you want encrypted, deduplicated backups without vendor lock-in — or need to consolidate scattered cloud and local data into a single encrypted repository — Cloudstic is worth a look.