true bidirectional with split truth modle set up. all scripts are fully bidirectional

Orchestrators/README-Orchestrators.md

@@ -135,6 +135,68 @@ The same share lists are used by `failover.sh` for Tier 4 writeback — but in t
 
 ---
 
+### `nightly_critical_full_sync.sh`
+
+Runs a clean nightly sync for Emby and the auth stack (Critical-Data) with containers stopped. This is the companion to the hourly dirty sync — it provides a fully consistent state on HOST2 once per night.
+
+```bash
+# Scheduled as: 30 2 * * *  (2:30am daily — after daily_sync.sh finishes)
+/mnt/user/appdata/unraid_scripts/Orchestrators/nightly_critical_full_sync.sh
+```
+
+**Why two Emby syncs:**
+
+The hourly dirty sync runs with Emby up — WAL files excluded, watch states pushed continuously. This means HOST2 is never more than an hour behind on watch state. But it's not a clean database snapshot.
+
+The nightly clean sync stops Emby, syncs the full clean database state, then restarts. HOST2 gets a fully consistent Emby state every night. The two syncs work together:
+
+```
+Hourly dirty sync (Emby running):
+  users.db, library.db, authentication.db, config/
+  WAL excluded — safe mid-write
+  HOST2 always within 1hr of HOST1 on watch state
+
+Nightly clean sync (Emby stopped):
+  Full clean snapshot — all databases flushed
+  No WAL files in flight
+  HOST2 gets gold-standard state once per night
+```
+
+**Why clean auth sync matters:**
+
+The auth stack runs warm on both servers continuously. During normal operation HOST2's auth stack serves its own domain — it doesn't receive dirty updates from HOST1. The nightly clean sync is the only time auth state propagates.
+
+This means:
+- New user added on HOST1 → propagates to HOST2 overnight automatically
+- Proxy rule changes → propagated overnight
+- No manual intervention needed for most auth changes
+
+For users who just want failover to work — this script handles it. No thinking required about dirty writes, WAL files, or when to sync.
+
+**What it syncs:**
+
+```
+Emby appdata:
+  users.db, library.db, authentication.db, config/
+  Containers stopped → clean flush → safe copy
+
+Critical-Data (auth stack):
+  NPM proxy rules + SSL certs
+  Authelia config + database
+  Mariadb-Authelia data
+  Redis-Authelia session store
+  LLDAP users and groups database
+  All auth containers stopped → clean databases → safe copy
+  Authelia delayed start on restart — Mariadb + Redis must be ready first
+```
+
+**What it excludes (per rsync profile):**
+
+```
+Emby:     logs, transcodes, cache, metadata, *.db-wal, *.db-shm
+Auth:     logs, *.tmp, nginx/temp, nginx/cache, notification.txt
+```
+
 ### `media_management.sh`
 
 Runs all media maintenance scripts sequentially in the order defined in `Master.conf`. Scheduled once daily, typically after the nightly sync.
@@ -240,12 +302,11 @@ This pattern means:
 # Recommended schedule
 */3 * * * *   transcode_management.sh    # cleanup then manager — every 3 minutes
 0 1 * * *     daily_sync.sh             # 1am — media shares to remote
-0 2 * * *     media_management.sh       # 2am — after sync completes
+0 2 * * *     media_management.sh       # 2am — permissions, cleaners, arr cleanup
+30 2 * * *    nightly_critical_full_sync.sh           # 2:30am — clean Emby + auth stack sync
 ```
 
-The 1 hour gap between them is intentional. `daily_sync.sh` can take 30-60 minutes on a large library. Starting `media_management.sh` before it finishes risks permission and cleanup operations running on files that are mid-transfer.
-
-If your sync consistently finishes well under an hour, reduce the gap. If it regularly runs long, increase it.
+The gaps are intentional. `daily_sync.sh` can take 30-60 minutes on a large library. `media_management.sh` starts at 2am giving daily_sync an hour to finish. `nightly_critical_full_sync.sh` starts at 2:30am giving media_management time to complete its permission and cleanup pass before Emby is stopped for the clean sync.
 
 ---