FailedProxy/Varaverk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rename: failover → fallback throughout codebase — this system is Fallback, state is FALLBACK; preserve conventional failover comparisons

Browse Source
This commit is contained in:
Gmer4Lfe
2026-06-01 20:04:17 -04:00
parent 65f6bd7b8a
commit cb7d7a688d
62 changed files with 85 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+23 -23
View File
@@ -5,7 +5,7 @@
**A complete self-healing, self-maintaining, mutually-redundant two-server unRAID
ecosystem.** One codebase runs on both servers. Both servers run their own lives
independently. When one goes down the other covers it — not because of conventional
failover infrastructure, but because both servers already have copies of everything
fallback infrastructure, but because both servers already have copies of everything
that matters and both know how to run it.
> **This is not conventional failover.** There is no primary and standby. There is no
@@ -38,7 +38,7 @@ HOST2 — unRAID-Jayred365
**Hardware does not need to match.** Everything is accessed through `/mnt/user/` —
unRAID's unified share layer. HOST1 has a Threadripper with ZFS. HOST2 has a completely
different CPU and fewer drives. A failover container on HOST2 mounts `/mnt/user/Movies`
different CPU and fewer drives. A fallback container on HOST2 mounts `/mnt/user/Movies`
and sees mirrored data because the share names match. The hardware underneath is
irrelevant.
@@ -60,7 +60,7 @@ break silently.
#
# The convention: "no suffix = this container participates in the shared stack"
#
Emby # the shared Emby — runs on HOST1, picked up by HOST2 on failover
Emby # the shared Emby — runs on HOST1, picked up by HOST2 on fallback
NginxProxyManager # shared NPM — runs on both, same config via sync
Lldap-Gmer4Lfe # shared LLDAP — same user directory, both servers
Authelia # shared auth — both servers, same config
@@ -93,7 +93,7 @@ codebase work on both servers without modification.
Immich-Gmer4Lfe # Gmer4Lfe's photo library — personal
```
User-specific containers are covered during failover (see Tiered Failover below) but
User-specific containers are covered during fallback (see Tiered Fallback below) but
are distinct from the shared stack. They are never confused with each other because
the suffix makes the owner unambiguous. Scripts targeting `Emby` and scripts targeting
`Emby-Gmer4Lfe` are targeting different containers for different purposes.
@@ -113,7 +113,7 @@ the suffix makes the owner unambiguous. Scripts targeting `Emby` and scripts tar
# → looks for exactly those names in docker ps
#
# A container named differently than expected is not found — no error, no restart,
# no failover coverage. It silently does not happen.
# no fallback coverage. It silently does not happen.
# Keep names consistent on both servers for shared containers.
# ─────────────────────────────────────────────────────────────────────────────
```
@@ -235,11 +235,11 @@ where determines whether you need encryption and whether sync failure matters.
---
### ── Shared Failover Shares — Sync Required ─────────────────────────────────
### ── Shared Fallback Shares — Sync Required ─────────────────────────────────
```bash
# ─────────────────────────────────────────────────────────────────────────────
# These shares enable failover — HOST2 must have current copies for the covered
# These shares enable fallback — HOST2 must have current copies for the covered
# services to work correctly when they start on HOST2.
#
/mnt/user/Media_Server/Emby # Emby userdata — watch history, playstates
@@ -248,7 +248,7 @@ where determines whether you need encryption and whether sync failure matters.
/mnt/user/Tv_Shows # media library content
/mnt/user/Music # media library content
#
# Sync failure here = failover runs but with stale data (acceptable) or missing
# Sync failure here = fallback runs but with stale data (acceptable) or missing
# data (problematic). These sync every night via daily_sync_maintenance.sh.
# Critical-Data and Emby also sync every 30 minutes via critical_sync_maintenance.sh.
# ─────────────────────────────────────────────────────────────────────────────
@@ -256,12 +256,12 @@ where determines whether you need encryption and whether sync failure matters.
---
### ── Non-Failover Shares — Sync as Backup, No Encryption Required ───────────
### ── Non-Fallback Shares — Sync as Backup, No Encryption Required ───────────
```bash
# ─────────────────────────────────────────────────────────────────────────────
# Some shares don't participate in failover — their container only runs on one
# server and is covered during failover from scratch (or not at all).
# Some shares don't participate in fallback — their container only runs on one
# server and is covered during fallback from scratch (or not at all).
# These shares can sync as offsite backup without encryption.
# Content is not sensitive — anyone with access to HOST2 could read it.
#
@@ -323,7 +323,7 @@ Two fully independent servers, each running their own household's services.
Each server has its own domain, its own users, its own media library management.
Each server is the primary for its own services every single day.
The "failover" component is additive:
The "fallback" component is additive:
When HOST1 goes down → HOST2 starts HOST1's containers on top of its own
When HOST2 comes back → HOST1's containers hand back cleanly
HOST2 never stopped running its own services during this entire time
@@ -378,7 +378,7 @@ This is not standby. This is mutual coverage between peers.
---
## ━━━ HOW FAILOVER ACTUALLY WORKS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## ━━━ HOW FALLBACK ACTUALLY WORKS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
`fallback.sh` runs on both servers as a continuous background process. Every 2 minutes
it pings two things: the other server's Tailscale IP, and `8.8.8.8`. The combination
@@ -387,7 +387,7 @@ of those two answers determines the current state.
```
Remote ping PASS + Internet PASS → NORMAL — both servers running independently
Remote ping FAIL + Internet PASS → FAILOVER — remote is down, start covering it
Remote ping FAIL + Internet PASS → FALLBACK — remote is down, start covering it
Tier 1 immediately: DDNS + Emby + Auth + VaultWarden + Live TV + Gitea
Tier 2 at 4 hours: NextCloud + Immich + Jellyseerr
Tier 3 at 12 hours: AdGuard + Uptime monitoring
@@ -410,12 +410,12 @@ DDNS last. Split-brain DNS is prevented by design.
## ━━━ THE AUTH STACK — WARM ON BOTH SERVERS ALWAYS ━━━━━━━━━━━━━━━━━━━━━━━━━━
NPM, LLDAP, Authelia, MariaDB, Redis — all running actively on both servers at all
times. Not cold standby. Not started at failover. Running right now, serving each
times. Not cold standby. Not started at fallback. Running right now, serving each
server's own domain.
```bash
# ─────────────────────────────────────────────────────────────────────────────
# Why this eliminates the failover dead zone:
# Why this eliminates the fallback dead zone:
#
# Cold standby approach: HOST1 goes down → DNS switches to HOST2 → HOST2 starts
# auth containers → 30-60 seconds before auth is ready → users hit the auth wall
@@ -454,7 +454,7 @@ Source of truth:
Config auth stack config ──→ mirrored every 30 min
Emby state watch history, playstates──→ dirty sync every 30 min
Failover coverage:
Fallback coverage:
If HOST1 down: — starts Emby, VaultWarden,
Dispatcharr, all arr stack
serves Gmer4Lfe.com via DDNS
@@ -489,7 +489,7 @@ varaverk/
├── Rsync/ ← Core rsync script — called per share with profile
│ README: README-Rsync_Setup.md
│
├── Fallback/ ← Mutual automatic failover — continuous background process
├── Fallback/ ← Mutual automatic fallback — continuous background process
│ README: README-Fallback.md
│
├── Watchdogs/ ← All watchdog scripts: resource, docker, system, stability
@@ -564,7 +564,7 @@ Array start (Varaverk event hook):
→ php_fpm_max_children.sh WebGUI tuning before first request
→ ramdisk_setup.sh create ramdisk before Emby starts
→ docker_network_connect.sh connect containers to extra networks
→ fallback.sh continuous — mutual failover state machine
→ fallback.sh continuous — mutual fallback state machine
Every 15 minutes:
watchdog_orchestrator.sh fires each watchdog in sequence
@@ -782,9 +782,9 @@ If you're setting this up from scratch on two servers:
4. Run initial sync to populate HOST2
bash daily_sync_maintenance.sh --log
5. Verify failover works before relying on it
bash failover_test.sh --dry-run first
bash failover_test.sh when ready — uses iptables simulation, no real downtime
5. Verify fallback works before relying on it
bash fallback_test.sh --dry-run first
bash fallback_test.sh when ready — uses iptables simulation, no real downtime
```
---
@@ -802,7 +802,7 @@ If you're setting this up from scratch on two servers:
| [README-Monitors.md](Monitors/README-Monitors.md) | Cert monitoring, SMART health, bandwidth tracking, health digest profiles |
| [README-Partnership.md](Partnership/README-Partnership.md) | Auth stack sharing, onboard/offboard/transfer lifecycle, deferred offboard |
| [Manual.md](Manual.md) | Complete setup guide — Tailscale, SSH keys, git clone, master.conf, Varaverk scheduler |
| [README-Tools.md](Tools/README-Tools.md) | failover_state_reset, skip list manager, emby_database_repair, container export |
| [README-Tools.md](Tools/README-Tools.md) | fallback_state_reset, skip list manager, emby_database_repair, container export |
| [README-Unraid_Essentials.md](unRAID_Essentials/README-Unraid_Essentials.md) | `git_pull_execute.sh`, `server_reboot.sh`, `mover_stop.sh`, `user_scripts_stop.sh` |
---