Update rsync docs: emby-fallback profile removed, Emby watch state now synced by play_state_sync.sh
This commit is contained in:
+8
-19
@@ -341,24 +341,9 @@ PROFILES["emby_CRITICAL_CONTAINER_NAMES"]=("Emby")
|
||||
PROFILES["emby_EXCLUDE_DIRS"]=(
|
||||
"transcodes/" "logs/" "crash*" "cache/"
|
||||
)
|
||||
|
||||
# ── emby-fallback ─────────────────────────────────────────────────────────────
|
||||
# Every 30 minutes, Emby STAYS RUNNING — dirty sync of critical state only
|
||||
PROFILES["emby-fallback_CRITICAL_CONTAINER_NAMES"]=() # nothing stops
|
||||
PROFILES["emby-fallback_EXCLUDE_DIRS"]=(
|
||||
"*.wal" "*.shm" # unsafe mid-write
|
||||
"transcodes/" "logs/" "crash*" "cache/"
|
||||
)
|
||||
PROFILES["emby-fallback_REMOTE_RESTART_CONTAINERS"]=("Emby")
|
||||
```
|
||||
|
||||
### Two Emby Profiles — Why Both Exist
|
||||
|
||||
**emby-fallback** (every 30 minutes, Emby stays running):
|
||||
- Syncs: users.db, library.db, authentication.db, config/
|
||||
- Skips: \*.wal, \*.shm, transcodes/, logs/, cache/
|
||||
- Why: WAL files are written while Emby runs — copying them would produce a corrupt database on HOST2
|
||||
- Result: HOST2 is always within 30 minutes of HOST1 on watch state and user activity
|
||||
### The `emby` Profile and Watch-State Sync
|
||||
|
||||
**emby** (Sunday 2:30am, both Emby instances stopped):
|
||||
- Syncs: everything except transcodes, logs, cache, crash files
|
||||
@@ -366,8 +351,12 @@ PROFILES["emby-fallback_REMOTE_RESTART_CONTAINERS"]=("Emby")
|
||||
- Why: WAL is checkpointed on clean shutdown — safe to copy everything
|
||||
- Result: HOST2 gets a gold-standard Emby state once per week
|
||||
|
||||
The two profiles work together. emby-fallback keeps HOST2 current for immediate fallback.
|
||||
emby gives HOST2 full fidelity once per week. Neither alone is sufficient.
|
||||
Between weekly mirrors, Emby **watch/resume state** is kept current by
|
||||
`Media/play_state_sync.sh`, which reads and writes play state over the Emby API every
|
||||
30 minutes (CRITICAL_MAINTENANCE_SCRIPTS) — so HOST2 never falls more than one cycle
|
||||
behind on what's been watched. This replaced the old `emby-fallback` dirty-rsync profile:
|
||||
copying Emby's live SQLite databases mid-write risked landing a half-written WAL file on
|
||||
HOST2, and an API-level sync sidesteps the database-consistency problem entirely.
|
||||
|
||||
---
|
||||
|
||||
@@ -705,5 +694,5 @@ name doesn't match any profile key, or when testing a specific profile.
|
||||
|
||||
```bash
|
||||
rsync.sh /mnt/user/appdata-Fallback/Critical-Data --profile=critical-data
|
||||
rsync.sh /mnt/user/Media_Server/Emby --profile=emby-fallback
|
||||
rsync.sh /mnt/user/Media_Server/Emby --profile=emby
|
||||
```
|
||||
|
||||
@@ -67,8 +67,8 @@ Orchestrators/ ← decides what to sync, when, and in what order
|
||||
weekly_sync_maintenance.sh ──────────────────────────────────► rsync.sh (emby, critical-data)
|
||||
critical_sync_maintenance.sh ────────────────────────────────► rsync.sh (partnership shares)
|
||||
|
||||
Cron (direct):
|
||||
*/30 * * * * ──────────────────────────────────► rsync.sh --profile=emby-fallback
|
||||
Note: Emby watch/resume state is NOT synced by rsync — Media/play_state_sync.sh
|
||||
does it over the Emby API every 30 min (CRITICAL_MAINTENANCE_SCRIPTS).
|
||||
|
||||
Monitors/
|
||||
bandwidth_monitor.sh ◄─── called by rsync.sh after each sync (--log-transfer)
|
||||
@@ -94,7 +94,6 @@ Profile key = directory basename lowercased. `--profile=name` overrides.
|
||||
| `critical-data` | Auth stack | Mariadb-Authelia, Redis-Authelia, NPM, Lldap | Authelia has restart delay |
|
||||
| `important-data` | NextCloud + Postgres | Postgres-NextCloud | NextCloud has restart delay |
|
||||
| `emby` | Full Emby mirror | Emby (both sides) | Weekly — Sunday 2:30am |
|
||||
| `emby-fallback` | Emby watch state delta | None | Dirty sync — Emby stays running |
|
||||
|
||||
For full profile definitions see `Manual-Rsync.md`.
|
||||
|
||||
@@ -104,7 +103,7 @@ For full profile definitions see `Manual-Rsync.md`.
|
||||
|
||||
| Script | Role | When It Runs |
|
||||
|--------|------|-------------|
|
||||
| `rsync.sh` | Core transfer engine — profile resolution, pre-flights, container management, transfer, bandwidth logging | Called by orchestrators; directly for manual and 30-min Emby dirty sync |
|
||||
| `rsync.sh` | Core transfer engine — profile resolution, pre-flights, container management, transfer, bandwidth logging | Called by orchestrators; directly for manual syncs |
|
||||
|
||||
---
|
||||
|
||||
@@ -116,7 +115,6 @@ Callers (Orchestrators/) ──────────────────
|
||||
weekly_sync_maintenance.sh rsync.sh /path/to/share [--profile=name] │
|
||||
critical_sync_maintenance.sh ─────────────────────────────────────────────► │
|
||||
fallback.sh (writeback) │
|
||||
Direct cron (emby-fallback) │
|
||||
▼
|
||||
┌─────────────────────────────────────┐
|
||||
│ 1. Infer/accept profile │
|
||||
|
||||
Reference in New Issue
Block a user