HetGuard – Automated backup scheduling for Hetzner Cloud
Hetzner-native backup automation with encrypted volumes and database exports to S3.
content-addressable, encrypted backup
Fixes Restic's cloud blindness by understanding Drive IDs, folder trees, and change APIs.
DevOps engineers, data protection teams, users managing hybrid cloud storage environments
Restic · Borg Backup · Duplicacy
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!
Hetzner-native backup automation with encrypted volumes and database exports to S3.
Printable QR + human-readable fallback for offline recovery, no cloud dependency.
Nice little CLI: one-liner install and an interactive 'clawstash setup' get you an hourly daemon that auto-downloads restic and uploads AES-256 encrypted, deduplicated blocks to any S3-compatible store. It's pragmatic and tightly scoped — excellent if you run OpenClaw, but mostly a focused wrapper around restic rather than a novel backup system.
Gzip breaks dedup; this stores uncompressed snapshots on BTRFS for 85% savings.
Cryptomator and Boxcryptor already do encrypted multi-cloud storage better.
Tailscale clone with phone backups, but the core mesh networking is already solved.