vitya
b332af66e4
VDS daily backup пал с 12.06 (line 108, exit 1): mssql-блок (added 11.06,
commit f8ca0794) использовал `WITH ... INIT`, упирался в компрессованный
media-header майских .bak (созданы WITH COMPRESSION на Developer-источнике).
Express не пишет в compression-форматированный media set -> Msg 1844, молчаливый
провал первым же cron-запуском. 5 боевых CMS-баз 3 недели без offsite-копии.
Fix: INIT -> FORMAT (всегда новый media set, иммунно к остаткам). Прогон
verified зелёным: VDS backup OK 95m41s, все 5 .bak на kreknin
(MoreThenCms 910M, StayerCalculator 528M, StayerPrice 39M, TireService 4.5M,
stostayer 990M), speedup 22.62 (--link-dest хардлинкует).
- scripts/vds-backup-rsync-kreknin/run.sh: синхронизирован с задеплоенным
(mssql-блока в репо не было); FORMAT
- .wiki/concepts/mssql-on-vds.md: gotcha #2 (INIT vs FORMAT) + backup-gap
- .wiki/concepts/backup-inventory-2026-06.md: новая — карта estate × что реально
бэкапится (с доказательством); триаж дыр
- openwrt UCI backup настроен (cron 03:30 -> kreknin, restricted forced-command
key) — документация в entity + inventory
- .tasks/kreknin-self-backup.md: backlog #1 SPOF (приёмник сам не бэкапится)
- STATUS.md: incident + audit summary
Урок: бэкап-шаг не готов, пока не предъявлен лог одного реального успеха;
прод-крон не должен быть первым тестом бэкап-пути.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
27 lines
2.2 KiB
Markdown
27 lines
2.2 KiB
Markdown
# kreknin-self-backup — второй таргет для приёмника бэкапов
|
||
|
||
**Status:** ⚪ backlog (на потом, по решению user 2026-06-12)
|
||
**Priority:** #1 среди backup-дыр (см. [[../.wiki/concepts/backup-inventory-2026-06]])
|
||
|
||
## Проблема
|
||
|
||
[[../.wiki/entities/kreknin-synology]] (`195.19.90.188`, `/volume1` 7.0 ТБ) — **единственный приёмник всех 4 бэкап-пайплайнов** (vds-kzntsv 05:00, books-vds 06:00, ruvds-iis 04:30, openwrt 03:30) и при этом **сам никуда не бэкапится**. Если его том откажет — одновременно теряются offsite-копии ВСЕХ машин. Худший single point of failure в estate.
|
||
|
||
Тип RAID не подтверждён («тип неизвестен» в entity). Hyper Backup vault (`diskstation_1.hbk`, 430 ГБ) на нём же — тоже не реплицирован вовне.
|
||
|
||
## Направление (не финал, обсудить при подъёме)
|
||
|
||
Второй таргет для критичного subset — облако:
|
||
- **Backblaze B2** (дёшево, S3-совместимо) или **S3 Glacier** (холодное, ещё дешевле, но retrieval-latency).
|
||
- Synology **Cloud Sync** (B2) или **Hyper Backup** (→ B2/S3) — нативные пакеты DSM.
|
||
- Минимальный subset: `/volume1/NetBackup/*/latest` каждого пайплайна + `*.hbk` vault. Полные 7 ТБ лить не нужно — только последние снапшоты.
|
||
- Шифрование на стороне DSM (Hyper Backup client-side encryption) — облако untrusted.
|
||
|
||
## Оценка
|
||
|
||
Объём critical-subset: vds-kzntsv ~2.4 ГБ MSSQL + ~12 ГБ stacks, books-vds ~5 ГБ, ruvds ~9 ГБ, openwrt 15 КБ → ~30 ГБ latest. B2 storage $6/ТБ/мес → копейки. Egress при restore — разовый.
|
||
|
||
## Decisions log
|
||
|
||
- **2026-06-12** — заведена по итогам backup-gap аудита (триггер: MSSQL 3-нед gap). User: «задача, но на потом». Не горит, но это #1 по риску среди оставшихся дыр.
|