Choose encryption according to who must be able to read your data. Always use HTTPS and keep recoverable copies of your encryption secrets outside the bucket they protect. Losing the only usable key or backup password can make your data permanently unreadable.
Three layers
| Layer | Who controls the secret? | Protects against | Does not protect against |
|---|---|---|---|
| SSE-S3: automatic server-side encryption | Impreza holds the server-side key | Reading ciphertext from a stolen storage disk without its keys | Impreza's storage administrators or a compromised server that can access the keys; a caller with valid read credentials |
| SSE-C: server-side encryption with your supplied key | You retain the key and send it over TLS for each relevant request | Reading stored ciphertext without the supplied key | A malicious or compromised storage server handling the key and plaintext during a request; a compromised client |
| Encryption on your device: rclone crypt or restic | You hold the encryption password/key; only ciphertext is uploaded | Impreza or the storage server reading the plaintext of objects encrypted before upload, provided your secrets stay on your device | A compromised client, stolen encryption secrets, deletion or denial of access; traffic timing, sizes and other exposed metadata |
SSE-S3 is automatic, but the key belongs to Impreza. It protects against a stolen disk, not against us. Because the server applies it with its built-in key service, object responses report x-amz-server-side-encryption: aws:kms; this is the same automatic, Impreza-held key, not a key you manage. SSE-C requires TLS: the storage server sees the supplied key during a request, so it is not end-to-end encryption. Keep the exact SSE-C key for each object version; an access key alone cannot recover an object if its encryption key is lost.
Only encryption performed on your own device keeps plaintext and encryption secrets from Impreza. Do not upload an unencrypted copy alongside the encrypted one. Encryption does not replace object lock, which controls when versions can be deleted.
rclone crypt
First configure an S3 remote as in the quick start. Run rclone config interactively and add a crypt remote wrapping impreza:YOUR_BUCKET/encrypted. Enable filename encryption if you want filenames encrypted too. Enter the encryption password and optional salt in the interactive prompts, not command arguments. Store a recovery copy of both separately. rclone's obscured configuration values are reversible: protect the configuration file or encrypt the configuration itself.
Use rclone copyto example.txt encrypted:example.txt to upload through that crypt remote and rclone copyto encrypted:example.txt restored.txt to decrypt locally. Uploads sent directly to the underlying S3 remote bypass crypt. Test the restore and compare it with the original.
See rclone crypt documentation for configuration and metadata limits.
restic
restic encrypts backup data before upload. Its repository password is separate from your S3 access keys: keep a recoverable copy of the password, protect the local device, and test restores. The restic quick start shows a backup and restore into a separate directory. Follow the restic encryption design when evaluating its protection and metadata.
Before choosing retention
Some backup tools delete or rewrite repository objects while pruning. An object-lock policy can prevent those operations until retention ends. Review the GOVERNANCE rules and backup compatibility before enabling retention. A successful upload alone is not a verified backup: test decryption and restoration too.