Connect S3
Configure an rclone remote for your bucket.
SYNOLOGY → S3 GLACIER DEEP ARCHIVE
Back up Synology to Glacier Deep Archive.
A self-hosted interface for choosing what to back up, creating dated TAR files, running dry runs and monitoring rclone jobs.
Taking advantage of AWS Deep Archive’s affordable price tier is a headache.
Synology Cloud Sync can copy files to S3, but checking a large NAS can generate thousands of API requests. In my case, that request overhead worked against the reason for choosing Deep Archive in the first place.
rclone was the logical alternative, but it has no GUI. Including and excluding folders is difficult if you are not comfortable with the command line. After Synology deprecated Glacier Backup, I built the visual interface I wanted as a designer: choose folders, preview a job and see what is happening.
How it works
Choose folders
Select exactly what is included or excluded.
Run the job
Dry run first, then copy now or on a schedule.
Move to Deep Archive
Your S3 lifecycle policy changes the storage class.
The manager does not create your AWS account, bucket or lifecycle policy. It uses the S3 destination you configure.
Back up selected folders
Add only the folders you want to protect. Exclude subfolders in the browser, preview the candidates with a dry run, then copy recent changes immediately or on a schedule.
- Source volumes are mounted read-only
- Existing S3 objects are not uploaded again
- One file or folder can be forced into the next upload
Create TAR archives of folders
Select one or more folders and package each as a separate dated TAR or TAR.GZ file. The source hierarchy can be reused at the destination, so an archive from /volume1/Docker/Persistent can be stored under Docker/Persistent.
- The original folder is never changed or deleted
- Available temporary space is checked before packaging
- Local packages are removed only after a successful upload
Run to a schedule
Choose when the nightly backup starts and how far back the recent-file window should look. You can pause scheduled and manual jobs without removing the configuration.
Limit the system overhead
Set the scan pace, CPU cores, thermal pause point, bandwidth and AWS request rate. The runner stops work at the upper temperature and resumes after the NAS cools.
Installation
Choose the layout of your Synology. The builder creates the complete Portainer stack and DSM runner command with the correct volume paths.
Deploy the Portainer stack
In Portainer, open Stacks → Add stack → Web editor. Name it glacier-backup-manager, paste this file and select Deploy the stack.
The selected source volumes are mounted read-only. Only the manager’s data and log folders are writable.
Open the manager and sign in
After Portainer finishes building the stack, open http://your-nas:8787. Create the local administrator account, then leave the backup engine paused until the test upload is verified.
Add the runner task in Synology DSM
Open Control Panel → Task Scheduler. Create a Triggered Task → User-defined script, run it as your dedicated backup user and set the event to Boot-up.
Run the task manually once after installation. Then add one harmless folder, run a dry run, upload one uniquely named test file and confirm it appears in S3.
Read the full installation reference →
Security
This is self-hosted software, not a managed backup service. You remain responsible for AWS permissions, NAS access, lifecycle rules, restores and independent verification.
Local administrator login
First launch requires a username and a password of at least 12 characters with uppercase, lowercase, a number and a symbol. Passwords are stored as salted PBKDF2-SHA256 hashes, never as plaintext.
Protected sessions
Sessions use random HttpOnly, SameSite cookies and CSRF tokens. Enable secure cookies when serving the interface over HTTPS. Login attempts are rate-limited.
Credentials stay with the runner
The web interface never displays stored AWS secrets. One-time configuration requests expire, are written with restrictive permissions and are passed to rclone via standard input rather than command history.
No destructive sync
Jobs rebuild mandatory arguments and use copy, --no-traverse and explicit source mappings. The application does not expose remote delete operations.
Do not expose the app directly to the public internet. Keep it on a trusted network or behind a properly configured HTTPS reverse proxy and additional access control. Review SECURITY.md before deployment.
Please remember
Set your bucket lifecycle rules to move objects into Deep Archive.
Glacier Backup Manager uploads to your S3 bucket, but it does not create AWS lifecycle rules or spending alerts. Complete both steps before relying on the backup.
Create the S3 Lifecycle rule
- In Amazon S3, open the destination bucket, then choose Management → Lifecycle rules → Create lifecycle rule.
- Apply the rule to the whole bucket or only the prefix used by this manager.
- Add a transition for current object versions to S3 Glacier Deep Archive after the number of days you choose. If bucket versioning is enabled, review noncurrent-version transitions as well.
- Save the rule and confirm uploaded objects eventually show the Deep Archive storage class.
Create an AWS Budget alert
- Open Billing and Cost Management → Budgets → Create budget, then choose a cost budget.
- Set a monthly amount that reflects the storage, request and restore costs you expect.
- Add email alerts for actual and forecasted spend—for example, an early warning and a second alert at your maximum comfortable amount.
- Check that the notification recipient is correct and review the budget after the first full billing cycle.
Worth knowing: new Lifecycle configurations do not transition objects smaller than 128 KB by default. Deep Archive also has a 180-day minimum storage duration and restores are not immediate. Packaging many small files into TAR archives can reduce per-object transition overhead.