Proton Drive CLI: Linux Server Backups

A practical example of automating Linux server backups to Proton Drive using Proton Drive CLI, Bash, and cron.

About this project

This project documents a real-world use case for Proton Drive CLI: automatically creating compressed backups of a Linux server and uploading them to Proton Drive, without requiring a graphical interface.

The workflow is based on a backup script that runs on a personal Debian VPS. The original script has been used in that environment to create archives, upload them to Proton Drive, and manage backup retention.

To make the project suitable for public sharing, the original script has been adapted to remove personal server paths and settings and to introduce generic, configurable values. These adaptations make the example easier to reuse, but they may also require further changes to match another system's configuration, permissions, and Proton Drive CLI installation.

The repository is intended as a learning resource and a starting point for adapting the workflow to other Linux environments. It is not a drop-in replacement for the original server script, nor is it guaranteed to work unchanged in production.

What the workflow does

The backup workflow is designed to:

1. Check that the required commands and Proton Drive destination are available.
2. Create a compressed archive using tar and Zstandard.
3. Upload the archive to a directory on Proton Drive.
4. Keep a configurable number of recent backups.
5. Remove the temporary local archive after execution.

The workflow can be scheduled using cron.

Requirements

The example is intended for a Linux system and requires:

• Proton Drive CLI, installed and authenticated.
• Bash.
• GNU tar with Zstandard support.
• sudo, configured for the required backup operation.
• jq, to process the JSON output used when listing remote backups.
• pass and GPG if using the corresponding Proton Drive CLI credential storage configuration.

Exact installation steps depend on the Linux distribution and the version of Proton Drive CLI being used.

Configuration

The script can be customized using the following environment variables:

Variable	Default value	Purpose
PROTON_DRIVE_BIN	/usr/local/bin/proton-drive	Path to the Proton Drive CLI executable.
PROTON_BACKUP_PATH	/my-files/Backups	Destination directory on Proton Drive.
KEEP_BACKUPS	7	Maximum number of matching backups to retain.
BACKUP_USER	Current username	User and group assigned to the temporary archive.
BACKUP_PREFIX	linux-system-	Filename prefix used for generated archives and backup rotation.
PROTON_DRIVE_CREDENTIALS_STORE	pass	Credential storage backend used by Proton Drive CLI.

The BACKUP_SOURCES array must be edited directly in the script. Add the absolute paths of the directories you want to back up.

For example:

BACKUP_SOURCES=(
    "/etc"
    "/home/my-user/scripts"
)

These paths are examples only. Choose the directories appropriate for your own server, and verify that the required permissions are in place before running the script.

The default configuration is intentionally incomplete: the script refuses to run until at least one valid backup source has been configured.

Security considerations

Do not upload real server backups to this repository.

Server backups can contain private SSH keys, credentials, certificates, tokens, personal data, and other sensitive information.

Before adapting a backup script:

• Review every directory included in the archive.
• Never commit credentials, private keys, tokens, or real backup archives.
• Use least-privilege permissions for backup operations.
• Keep authentication material outside the repository.
• Review the Git history before publishing changes.
• Test the restoration procedure separately and verify that the required files can actually be recovered.

The scripts published here must use generic paths and example settings. They must not contain personal server configuration or authentication data.

Technical choices and customization

Backup rotation

The script uses a configurable filename prefix to identify the backups it manages. It retrieves the remote file list using Proton Drive CLI, extracts filenames with jq, and sorts them with sort to identify the oldest backups when the retention limit is exceeded.

This approach reflects the original server setup, where the remote directory is intended to contain the relevant backup archives.

The current implementation filters filenames by prefix. It does not explicitly check for the .tar.zst extension.

Possible customization: if the remote directory also contains unrelated files sharing the same prefix, the filter could be extended to check the expected file extension or the complete filename format. Whether this additional filtering is useful depends on how the remote directory is organized.

Temporary archive and permissions

The archive is created in /tmp using sudo. Its ownership is then changed so that the user running the script can upload it to Proton Drive without running the Proton Drive CLI with elevated privileges.

This approach was chosen to work with the original server's restricted sudoers configuration. The required permissions must be reviewed and adapted to each environment.

These technical choices come from a real-world use case. They are not intended to be universal requirements, and users should verify that they fit their own systems and security policies.

The temporary archive filename includes a timestamp with minute-level precision. Avoid running multiple instances of the script concurrently or scheduling overlapping executions, as they could target the same temporary filename.

Development approach and AI assistance

This project was developed through a collaborative process involving the repository maintainer and an AI assistant.

The AI assistant helped explore possible solutions, explain commands, draft and review scripts, and troubleshoot issues. The maintainer reviewed the suggestions, asked questions, made implementation decisions, and ran the checks described in the project.

AI assistance does not replace independent review. The examples should be checked and tested in the intended environment before being used for important data. This acknowledgement describes the development process; it does not imply that the AI assistant is a human co-author or that every generated element is necessarily eligible for copyright protection.

Status and limitations

The project is based on a backup workflow used on a real Debian server. However, the public version has been adapted for anonymity and reuse, so its behaviour may differ from that of the original script in its intended environment.

The current checks cover Bash syntax and a limited, standalone test of archive filename selection. They do not constitute an end-to-end test of the public script against a real Proton Drive account. Restoration has not yet been verified.

Before using the script in production:

• Review and configure the directories to back up.
• Adapt the Proton Drive destination, command path, user and permissions to your environment.
• Check compatibility with your installed Proton Drive CLI version.
• Review the backup rotation behaviour and the files it may move to the Proton Drive trash.
• Run a complete backup test and verify that the resulting archive can be downloaded and restored.

A successful syntax check or upload alone does not prove that a backup can be restored. Test the complete process before relying on it to recover important data.

Contributing

Suggestions, corrections, and improvements are welcome.

Please do not submit personal data, real server archives, credentials, private keys, or other sensitive configuration.

Licensing

• Scripts and tests: MIT License, in the LICENSE file.
• README and documentation: Creative Commons Attribution 4.0 International (CC BY 4.0), described in LICENSE-DOCS.md.

Unless a file says otherwise, the MIT License applies to source code and tests, while CC BY 4.0 applies to prose documentation. Third-party materials, if any are added later, remain subject to their own licenses.

Disclaimer

The examples are provided "as is", without warranty. You are responsible for reviewing, adapting, and testing them before use.