This manual is for people who run and manage iOS Backup at home. Its steps have been checked against the current code, interface, and available test records. Use Docker Compose on a general Linux host, or follow the separate Synology guide. Chinese and English cover the same tasks. If this is your first installation, start with the illustrated Quick start.
Before enabling a schedule, complete one USB backup on a non-critical device , reserving space for a complete device backup . There is no record of a successful physical-device restore using this manual yet. Check backup completion, file-list readability, and device restoration separately.
Choose a task
Section titled “Choose a task”| Task | What you should be able to confirm |
|---|---|
| Check prerequisites and support boundaries | Decide whether the host, access and feature maturity fit your needs |
| Install, log in and change the administrator password | Create a new instance and verify version and persistence |
| Deploy on Synology DSM | Check Container Manager, Compose, USB and directory permissions |
| Pair over USB and complete a first backup | Respond to passcode or trust prompts, pair, start and confirm the actual result |
| Schedule automatic backups | Set window, interval, battery and charging rules, then observe a run |
| Enable and validate Wi-Fi backup | Prepare on a computer, pair on the NAS, validate Wi-Fi and fall back to USB |
| Manage backup encryption and passwords | Distinguish four credentials and handle existing encrypted backups |
| Inspect backups and export file lists | Understand the 5,000-entry limit and what CSV contains |
| Configure and verify notifications | Save rules, check test delivery and observe a real event |
| Manage devices and storage | Remove and re-add devices, check capacity and protect copies |
| Restore device data: overview and preparation | Protect the backup and check Finder / Apple Devices prerequisites and validation gaps |
| Back up, migrate and recover the instance | Protect the key, configuration, pairing records and backup sets together |
| Upgrade and rollback | Pin images, validate the upgrade and retain a rollback path |
| Evaluate experimental operations | Understand the requirements, risks, and tested scope of unpack, deletion, and device restore |
| Troubleshoot by symptom | Use the page and logs for simple checks, then decide whether to retry or request help |
| Look up configuration, paths and applying changes | Distinguish program/Compose defaults and per-device settings |
| Understand states, progress and errors | Interpret phases, inactivity deadlines and success criteria |
| Investigate advanced Wi-Fi / NAT issues | Investigate routed networks and idle connections after a USB comparison |
Routine checks
Section titled “Routine checks”Run in the actual Compose deployment directory, replacing 9000 if changed:
docker compose pscurl -fsS http://127.0.0.1:9000/healthzcurl --user iosbackup http://127.0.0.1:9000/api/versiondocker compose logs --tail=200 iosbackupcurl prompts for the administrator password. /healthz confirms only that HTTP responds, not device readiness, writable storage or recoverable backups. Logs may include device/network details; sanitize before sharing. There is no public log-download API.
Access and data boundaries to retain
Section titled “Access and data boundaries to retain”The privileged container uses host networking and USB/udev mounts. Deploy only on a trusted host and restricted LAN/VPN, keep authentication enabled, and do not expose it to the public Internet. Use suitable HTTPS and access control across networks.
Persist and protect /backups, all of /configs (including default secret_key, password, and digest), /var/lib/lockdown, all Compose configuration files, and external credentials in use. Keep administrator passwords, master keys, backup passwords, pairing records and user data out of public issues. The container image does not include this data. See feature status for Core and Experimental boundaries.
Documentation and verification materials
Section titled “Documentation and verification materials”- Development guide and offline testing guide: reproduce software checks; these are not device-compatibility or restoration guarantees.
- Support, privacy and security reporting: collect sanitized context/logs for ordinary issues and use private reporting for vulnerabilities.
“Source checked” means the procedure matches the current implementation. Existing device test records apply only to the devices, versions, and operations recorded. Other devices need their own tests.