Disaster Recovery
This guide covers recovery procedures for all major failure scenarios in SyncID.
1. Application crash or restart
Section titled “1. Application crash or restart”Automatic recovery
Section titled “Automatic recovery”| Mechanism | Behavior |
|---|---|
| Auto-restart | The server automatically restarts SyncID after a crash |
| Task persistence | All scheduled tasks resume automatically on restart |
| Startup notification | If the app fails to start, an email with diagnostics is sent to admin addresses |
| Downtime sync | On restart, SyncID automatically collects attendance records that were generated on devices while the app was down |
Manual recovery
Section titled “Manual recovery”- If the application did not auto-restart, start it manually from the server
- Verify at the health dashboard — all checks should show Healthy
- Confirm that scheduled tasks are running normally
2. Database failure
Section titled “2. Database failure”Transient database outage
Section titled “Transient database outage”No action required. SyncID retries database connections automatically. Scheduled tasks retry on their next run.
Database corruption or loss
Section titled “Database corruption or loss”- Locate the latest backup — SyncID creates a database backup before every update automatically
- Restore the backup using your SQL Server management tools
- Restart the application — any pending updates will be re-applied
- Verify data integrity:
- Check employee counts match SyncrOne
- Check device list is complete
- Review attendance records for gaps
Complete database loss (no backup)
Section titled “Complete database loss (no backup)”- Start with a fresh database — SyncID sets it up automatically on first startup
- Trigger an employee sync to re-pull all employees from SyncrOne
- Attendance records are the critical loss — records already sent to SyncrOne are safe, but unsent local records are lost
- Device enrollments on physical devices are unaffected — employees can still authenticate
3. Device connectivity issues
Section titled “3. Device connectivity issues”Automatic safeguards
Section titled “Automatic safeguards”| Safeguard | Detail |
|---|---|
| 3-strike detection | After 3 consecutive failed checks (30 min), an admin email alert is sent |
| Automatic reconnection | When a device comes back online, missed attendance records are synced automatically |
| Recovery notification | When an offline device comes back online, a recovery email is sent |
Single device offline
Section titled “Single device offline”- Check physical connectivity — power, network cable, IP address
- Ping the device from the SyncID host
- Verify TCP port 4370 is not blocked
- Check if the device IP changed (DHCP lease renewal)
- Once reconnected, SyncID automatically syncs missed records
All devices offline
Section titled “All devices offline”- Check network infrastructure — switches, routers, VLANs
- Verify the SyncID host has connectivity to the device network segment
- Check firewall rules for port 4370
During device downtime
Section titled “During device downtime”- Devices continue to operate independently — employees can still authenticate
- Records are stored on-device — devices have internal storage for logs
- Records sync when connectivity restores — no manual intervention needed
4. SyncrOne API outage
Section titled “4. SyncrOne API outage”Impact during outage
Section titled “Impact during outage”| Function | Impact |
|---|---|
| Device management | Fully operational |
| Attendance collection | Fully operational — records queue locally |
| Attendance delivery | Blocked — records queue locally until SyncrOne is available |
| Employee sync from SyncrOne | Blocked until SyncrOne is available |
| Login / user management | Fully operational |
Recovery
Section titled “Recovery”No manual action required. When SyncrOne comes back online:
- SyncID detects the restored connection automatically
- Queued attendance records are delivered on the next scheduled run
- Employee sync resumes on the next scheduled run
5. Notification service outage
Section titled “5. Notification service outage”- Email notifications stop (device offline alerts, startup errors)
- Health dashboard shows Degraded for Notification Service
- All other functionality is unaffected
- No action needed within SyncID — coordinate with the notification service team
6. Host machine failure
Section titled “6. Host machine failure”Recovery: Same machine
Section titled “Recovery: Same machine”- Restore the machine to operational state
- Verify the database is running
- Start the SyncID application
- SyncID automatically resumes tasks and syncs missed records
Recovery: New machine
Section titled “Recovery: New machine”- Install SyncID following the installation guide
- Restore the database from backup
- Copy the configuration files from the old installation
- Start and verify at the health dashboard
7. Preventive measures
Section titled “7. Preventive measures”Backups
Section titled “Backups”- Schedule regular database backups (daily recommended)
- Store backups on a separate drive or network share
- Back up configuration files whenever settings change
- Keep at least 3 recent installation packages
Monitoring
Section titled “Monitoring”- Configure Teams webhook for real-time alerts
- Monitor the health dashboard regularly
- Review scheduled tasks weekly for failures
Testing
Section titled “Testing”- Test database restore from backup quarterly
- Simulate device offline scenarios to verify alerts work
- Verify SyncrOne recovery by temporarily blocking the API
Recovery time estimates
Section titled “Recovery time estimates”| Scenario | Expected Recovery |
|---|---|
| Application crash (auto-restart) | Seconds — automatic |
| Transient database error | Seconds — automatic retry |
| Device offline | Minutes — auto-detected within 30 min, auto-syncs on reconnect |
| SyncrOne API outage | Minutes — auto-recovers, records queued locally |
| Database restore from backup | 15–30 minutes |
| Full host machine rebuild | 1–2 hours (with documented setup and backups) |