Backup and restore for digital signage covers three layers: content files (Elementi projects), player configurations (network, security, display settings), and fleet state (Arya registrations, group assignments). SpinetiX's architecture simplifies disaster recovery: content lives in Elementi projects, configuration exports from one player import to another, and Arya cloud retains fleet assignments centrally. A complete player replacement takes under 30 minutes.
When to Use This Guide
- Before deploying to production — establish backup procedures for new installations
- After a player failure — restore content and config to a replacement unit
- Before firmware updates — backup current state in case a rollback is needed
- Compliance requirements — document your disaster recovery process for IT audits
What to Backup
Layer 1: Content (Elementi Projects)
Your Elementi project folder is the source of truth for all content. It contains SVG templates, images, data source configurations, and scheduling rules. Backup this folder to:
- Git repository — version-controlled, with history and rollback capability
- Network share — automated daily backup from your design workstation
- Cloud storage — Nextcloud, OneDrive, Google Drive for off-site protection
If using Arya, content is stored in the cloud platform. Backup is handled by SpinetiX infrastructure. For additional protection, export content locally at regular intervals.
Layer 2: Player Configuration
Each player has settings: IP address, hostname, admin password, TLS certificates, display output configuration, content source URL. Export configuration through the player's web interface → System → Export Configuration. This produces a file that can be imported on a replacement player.
| Configuration Item | Where Stored | How to Backup |
|---|---|---|
| Network settings | Player internal | Export via web interface |
| TLS certificates | Player trust store | Back up certificate files separately |
| Admin credentials | Player internal | Document in a password manager |
| Display settings | Player internal | Export via web interface |
| Content source URL | Player internal | Document in deployment records |
Layer 3: Fleet State (Arya)
For Arya-managed fleets, the cloud platform records all player enrollments, group assignments, and content mappings. If a player dies, replace it, enroll the new unit in Arya, assign it to the same group — content pushes automatically. No local backup needed for cloud-managed fleets.
Disaster Recovery Procedures
Scenario 1: Single Player Failure
- Replace the failed player with a new unit
- Configure network (static IP or DHCP) to match the failed unit
- Import configuration from backup (web interface)
- Publish content from Elementi or enroll in Arya
- Verify: content plays correctly, data feeds connect, schedule works
Recovery time: 15–30 minutes.
Scenario 2: Multiple Player Site Recovery
- Pre-configure replacement players with golden configuration template
- Ship to site, mount, and connect to network
- Bulk publish content from Elementi or re-enroll in Arya by group
- Verify video wall sync, data feeds, and scheduling
Recovery time: 1–2 hours for a 10-player site.
Scenario 3: Design Workstation Loss
- Restore Elementi project files from Git/network backup
- Install Elementi on a new workstation
- Open the restored project — all content, data sources, and schedules are in the project folder
- Resume publishing to existing players
Recovery time: 30–60 minutes.
Key Parameters
| Parameter | Best Practice | Why It Matters |
|---|---|---|
| Backup Frequency | After every content change | Minimizes data loss window |
| Content Backup | Git + network share | Version history + off-site protection |
| Config Backup | Export per player annually | Fast replacement without reconfiguration |
| Recovery Time | 15–30 min (single player) | Minimal downtime for failing screens |
| Testing | Annual DR drill | Verify backup restores successfully |
Common Mistakes
- No backup at all. "It's just signage" — until a player dies and nobody has the content files, the templates, or the data source configurations. Set up automated backups from day one.
- Backing up content but not configuration. Content alone isn't enough. Network settings, certificates, and display configuration are needed for a full restore. Export player configs after every significant change.
- Not testing restores. A backup that can't be restored is worthless. Test your restore process annually. Simulate a player failure, restore from backup, and verify everything works.
- Single copy, single location. A backup on the same machine as the original protects against file corruption but not hardware failure or theft. Maintain at least two copies in different locations.
- Forgetting certificates. If you use custom TLS certificates, back them up separately. Certificate re-issuance can take days — having backups means instant restoration.