> How to automate offsite encrypted backups with Proton Drive CLI

Regular, offsite backups protect critical data against hardware failure, ransomware, and local disasters. But developers, sysadmins, and privacy-conscious power users who run headless servers or scheduled scripts can’t rely on manual uploads through a browser or desktop app. With the release of the Proton Drive CLI (command line interface), you can bring Proton’s zero-knowledge end-to-end encryption (E2EE) into your cloud backup automation: your backup scripts and scheduled shell workflows. Using the CLI effectively requires understanding its role. This guide explains why a CLI-driven backup architecture beats continuous background syncing, how conflict strategies handle file revisions, and how to schedule fully encrypted offsite backups on Linux, macOS, and Windows. What is an offsite backup and why does it matter? Why encrypt your offsite backups? Atomic scripting vs. background sync in the Proton Drive CLI How conflict strategies manage incremental backups Setting up an automated encrypted backup: A step-by-step guide Best practices Your offsite backup, encrypted and automated What is an offsite backup and why does it matter? If your backup lives on the same machine as your data, it’s not really a backup. Hardware fails. Ransomware encrypts everything it can reach, including connected drives. A fire, a flood, or theft doesn’t distinguish between your primary disk and the backup drive sitting right next to it. The 3-2-1 backup rule exists for this reason: Keep at least 3 copies of your data, on at least 2 different media, with at least 1 copy offsite. That offsite copy, which is supposed to be geographically separated from your other backups and the main data, is your last line of defense, so it must sit somewhere a local failure can’t reach. If it lives in the cloud, the service provider must not be able to read it either. This is where the Proton Drive CLI comes in. Why encrypt your offsite backups? Storing a backup offsite means trusting a third party with your data: a remote server out of your control, run by a company whose ownership or policies can change, and whose infrastructure can be subpoenaed or breached. End-to-end encryption solves this. Your files are encrypted on your device before they leave it. If the cloud server is compromised, there is nothing readable on it for an attacker, the provider, or anyone without your decryption key. Proton Drive uses end-to-end encryption by default for everything uploaded through the desktop apps, mobile apps, and CLI. Your encrypted offsite backup is protected by the same zero-access architecture that Proton built for Proton Mail, under strict Swiss privacy laws. Understanding the Proton Drive CLI: Atomic scripting vs. background sync The CLI works differently from a desktop sync app: Desktop and mobile apps (sync engines) run continuously in the background. They watch for file changes and copy every addition, edit, and deletion to the cloud. Proton Drive CLI (atomic execution engine) runs a single command, such as upload, download or list, then exits. It doesn’t watch local folders or run in the background. Why an atomic CLI makes sense for security and backups A continuous sync daemon mirrors your data, so it fails the 3-2-1 test. If a file is deleted locally, whether by accident, a script error, or ransomware, the deletion reaches the cloud immediately. And if an attacker breaches your system while the daemon runs, they could read its active session tokens. The CLI solves this by enabling periodic, scheduled backups. You invoke it, it executes, it stops, and it leaves behind a secure point-in-time recovery snapshot you can fall back on if a file is accidentally deleted or corrupted locally. Note: The CLI is not a complete backup solution on its own. You still decide what to back up, how often, how many versions to keep, and how to test your restores. How conflict strategies manage incremental backups By design, unmodified identical files are automatically skipped by the CLI to save bandwidth. However, when a file has been modified locally, you must tell the CLI how to handle it using conflict strategies. Avoid using skip for backups. While it prevents duplicate work, it will ignore modified files entirely. Instead, choose the strategy that fits your retention needs: --file-conflict-strategy create-new-revision (recommended for backups) uploads the changed file as a new version and keeps its history. The number of versions kept depends on your plan, and versions take up storage. --file-conflict-strategy rename adds a suffix to the modified file name and keeps both copies. --file-conflict-strategy replace overwrites the previous file with the new one. The old version is lost. --file-conflict-strategy skip ignores any file that already exists in the cloud, so changes are never saved (not recommended for backups).Example of an incremental upload command: proton-drive filesystem upload ./my-local-data /my-files/Backups/Daily \--folder-conflict-strategy merge --file-conflict-strategy create-new-revision Setting up an automated encrypted backup: A step-by-step guide What you need: A Proton account (free or paid; storage limits apply) The Proton Drive CLI binary for your platform (Linux, macOS, or Windows) A shell environment (Terminal, Bash, Sh, PowerShell) A task scheduler for automated runs: cron (Linux/macOS) or Task Scheduler (Windows) Step 1: Sign in and run a manual test Before setting up automation, authenticate your device interactively: proton-drive auth login How headless authentication works: When you run auth login on a server without a browser, such as a remote VPS or home Linux node, the CLI prints a sign-in URL. Open it on any device with a browser, like your laptop or phone, and complete the sign-in. The server is then signed in. Tip for headless servers / cron: For headless and automated systems running via cron, it is recommended to use pass as your credential store. Set it with this environment variable:export PROTON_DRIVE_CREDENTIALS_STORE="pass"). Standard OS keyrings (libsecret / GNOME Keyring) depend on active GUI desktop sessions, which cron jobs don’t have. Setting up pass avoids D-Bus session issues. Step 2: Write the backup script Create a shell script, such as backup.sh, that defines your source paths, handles keyrings, and runs the upload: #!/usr/bin/env bashset -euo pipefail# Define variablesLOCAL_DIR="/var/backups/data"REMOTE_DIR="/my-files/AutomatedBackups"export PROTON_DRIVE_CREDENTIALS_STORE="pass"# Execute idempotent uploadproton-drive filesystem upload "$LOCAL_DIR" "$REMOTE_DIR" \ --folder-conflict-strategy merge \ --file-conflict-strategy create-new-revision \ --json > /var/log/proton-backup-$(date +%Y%m%d-%H%M%S).jsonecho "Backup completed successfully at $(date)" Step 3: Schedule the backup with cron or systemd timers To run this backup nightly at 2:00 AM using cron: Open your crontab editor and add: crontab -e Add the scheduled execution entry: 0 2 * * * /usr/local/bin/backup.sh >> /var/log/proton-backup.log 2>&1 Best practices for automated offsite backups A working script is only the start. These three habits keep your offsite backup complete, easy to monitor, and within your storage limits. Test your recovery: A backup without a working restore is as good as no backup. Keep a restore script ready, built on proton-drive filesystem download, and test it regularly so it works when an incident hits. Log in machine-readable formats: Add --json to your scripts to output structured JSON logs. You can then parse job status with jq or trigger a webhook when a backup fails. Respect fair use: Don’t schedule high-frequency uploads, such as every 60 seconds. A daily or weekly schedule is enough for offsite backups. Your offsite backup, encrypted and automated Your backups are only as safe as the place you send them. With the Proton Drive CLI, every nightly job sends an encrypted offsite backup that no one can read but you. Not attackers, not your hosting provider, not Proton. You get end-to-end encryption, the legal shelter of Swiss privacy law, and open-source code that has been independently audited. You also keep full control of your backup pipeline: what runs, when it runs, and how long each version stays. Setup takes minutes. Download the CLI for Linux, macOS, or Windows, run your first manual backup, then schedule it and stop thinking about it. Download Proton Drive CLI View business plans