fixed needed readme's over the writeback change

This commit is contained in:
2026-04-19 16:20:22 -04:00
parent 4399c81b6e
commit af14a5ca2c
3 changed files with 112 additions and 42 deletions
+35 -10
View File
@@ -59,38 +59,63 @@ Every cycle `transcode_management.sh` records stats to `/boot/config/transcode_d
### `daily_sync.sh`
Syncs all bulk media shares to the remote server sequentially. Scheduled once daily.
Syncs each server's source-of-truth media shares to the remote server sequentially. Each server only pushes the shares it owns — direction and share list are automatic based on which server is running the script.
```bash
# Scheduled as: 0 1 * * * (1am daily)
# Scheduled as: 0 1 * * * (1am daily — on both servers)
/mnt/user/appdata/unraid_scripts/Orchestrators/daily_sync.sh
```
**Bidirectional — same script, correct direction automatically:**
```
HOST1 runs daily_sync.sh → pushes HOST1_DAILY_SYNC_SHARES → TO HOST2
Movies, Tv_Shows, Music, Books etc. — HOST1 is source of truth
HOST2 runs daily_sync.sh → pushes HOST2_DAILY_SYNC_SHARES → TO HOST1
Anime_Shows, Anime_Movies — HOST2 is source of truth
```
`detect_hosts()` determines which server is local at runtime and selects the correct share list. No script changes needed to reconfigure who syncs what — only `Master.conf` changes required.
**What it does:**
1. Detects local and remote server via `detect_hosts()`
1. Detects local server via `detect_hosts()` — determines HOST1 or HOST2
2. Resolves remote Tailscale IP
3. Runs a single pre-flight check — connectivity + remote rootfs
4. Iterates through every share in `DAILY_SYNC_SHARES`
5. Calls `Rsync/rsync.sh` for each share
6. Tracks pass/fail and duration per share
7. Reports a combined summary
4. Builds share list from `HOST1_DAILY_SYNC_SHARES` or `HOST2_DAILY_SYNC_SHARES`
5. Appends personal shares (`HOST1_PERSONAL_SHARES` or `HOST2_PERSONAL_SHARES`)
6. Calls `Rsync/rsync.sh` for each share
7. Tracks pass/fail and duration per share
8. Reports a combined summary
**Why one pre-flight check upfront:**
Connectivity and rootfs are checked once before the loop starts — not once per share. If the remote is unreachable or the rootfs is nearly full, the whole run fails fast before attempting 12 shares. Individual share existence and disk checks still run per-share inside `rsync.sh`.
Connectivity and rootfs are checked once before the loop starts — not once per share. If the remote is unreachable or the rootfs is nearly full, the whole run fails fast. Individual share existence and disk checks still run per-share inside `rsync.sh`.
**Configuration:**
```bash
# Master.conf — add or remove paths to control what syncs nightly
DAILY_SYNC_SHARES=(
# Master.conf — per-host share lists
# HOST1 truth shares — pushed from HOST1 to HOST2 nightly
HOST1_DAILY_SYNC_SHARES=(
/mnt/user/Movies
/mnt/user/Tv_Shows
/mnt/user/Music
# ...
)
# HOST2 truth shares — pushed from HOST2 to HOST1 nightly
HOST2_DAILY_SYNC_SHARES=(
/mnt/user/Anime_Shows
/mnt/user/Anime_Movies
# ...
)
```
These shares use global rsync defaults — no profile needed. For shares requiring custom bandwidth limits, container stops, or different rsync options, create a named profile in the Rsync profile system and call `rsync.sh` directly on a separate schedule instead.
**Relationship to failover writeback:**
The same share lists are used by `failover.sh` for Tier 4 writeback — but in the opposite direction. If HOST1 was down for 18hr+ and HOST2's arrs downloaded new content, Tier 4 writeback pushes `HOST1_DAILY_SYNC_SHARES` FROM HOST2 back TO HOST1. No duplicate configuration needed.
**Example output:**
```
━━━ 🔄 Daily Sync Starting — 2026-04-14 01:00:00 ━━━