OpeItcLoc03/admin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
03607d0d6e2babdb103de8447a79903141f6e01a
admin/.wiki/entities/kreknin-synology.md
vitya 1a901b1396 meta(handoff): kreknin rescue session — sdd/VM-volume restore + full rescue to USB + backups paused (→ repair) 
- kreknin Xpenology degraded after compressor dusting (sdb cable lost, md3 degraded, sda/sdc flaky cables)
- sdd/VM-volume (md2, /volume2) restored: DSM Repair + "Convert to read/write", scrub 0 errors
- full rescue 2026-08-02 → USB 2TB btrfs /mnt/rescue (netbackup/*.tar incl. diskstation_1.hbk 430G + 5 user shares)
- daily backups DISABLED (vds-kzntsv 05:00 + books-vds 06:00) — re-enable after repair
- wiki entity kreknin-synology: disk inventory, incident, repair, rescue, plan
- task kreknin-repair-md3-rebuild created (power-off → reseat cables → Repair md3 → re-enable backups)

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-03 12:40:51 +03:00

9.2 KiB
Raw Blame History

title, type, tags, sources, updated
title type tags sources updated
Kreknin Synology (backup target + DDNS) entity
hardware
nas
synology
backup
hyperbackup
../sources/nas-recovery-session-2026-05-18.md
2026-05-19

Kreknin Synology

Удалённая (географически в другом месте) Synology, которая держит Hyper Backup-репо мёртвой синки и сама работает как живой сервер.

Доступ

  • Public IP: 195.19.90.188
  • DDNS: kreknin.site (резолвится на 195.19.90.188)
  • DSM web: http://kreknin.site:5000 (HTTP; HTTPS 5001 наружу НЕ проброшен)
  • SSH: vitya@195.19.90.188:22 (был пароль, сейчас SSH-ключ установлен — id_ed25519_kreknin)
  • Канал: "не очень надёжный" по словам пользователя — поэтому неудобно держать там production-сайты.

Ограничения SFTP

  • SFTP-подсистема DSM запускается отдельно от SSH — Control Panel → File Services → FTP → SFTP. Изначально не была включена.
  • После включения SFTP — DSM jail-chroot'ит подсистему в home юзера. То есть vitya через SFTP видит только /volume1/homes/vitya/, не /volume1/backup/....
  • Обход: scp -O (legacy SCP протокол) использует чистый SSH-channel мимо SFTP-subsystem → даёт доступ ко всему, что shell-пользователь видит.

Структура

  • Volume: один том /volume1, 7.0 TB, ~1.2 TB used до восстановления.
  • /volume1/NetBackup/diskstation_1.hbk — Hyper Backup репо с мёртвой синки. 430 GB compressed (deduplicated), последняя успешная backup-версия 2026-05-09 05:06.
  • Hyper Backup Vault установлен как пакет на этой синке (см. hyper-backup-structure-and-recovery).
  • Owner данных в репо — vitya:users (POSIX) с ACL под +. ACL даёт vitya read, но individual файлы .bak/.acme.json могут иметь -rw------- — для них нужен chmod -R a+rX из root SSH.

VMM статус

  • Установлен (виден @SavedVM в /volume1/).
  • В сессии 2026-05-18 рассматривался вариант поднять snolla.ova прямо здесь через VMM как альтернатива переезду на Windows — отвергнут потому что канал не надёжный.

Роль в recovery

  • Источник всех данных: OVA, sql дампы, docker volumes (mssql, minio, elasticsearch, imgproxy/nginx) — всё тащилось отсюда.
  • Не было записи на этот NAS во время recovery — только чтение / Hyper Backup restore во временную папку /volume1/NetBackup/restore-tmp/, потом backup-shares /volume1/backup/, /volume1/docker/, /volume1/work/.

Гипотеза по будущему backup pipeline

  • Эта синка остаётся как backup target, на ней нет SMR-дисков (тип неизвестен на момент сессии, но кратко проверить через ls /dev/sd* + smartctl до тяжёлой нагрузки).
  • Будущая future-resilient-architecture-goals: добавить второй backup target (или облачный — Backblaze B2 / S3 Glacier), чтобы не зависеть от одной коробки.

Роль источника для миграции на VDS (2026-05-20)

В сессии vds-kzntsv-bootstrap-2026-05-20 kreknin сыграл вторую роль — источник данных для миграции инфра-сервисов на vds-kzntsv. Из restored backup'а (Hyper Backup .hbk мёртвой синки):

  • Gitea — tar c -C /volume1/docker/gitea data postgres docker-compose.yml | ssh vds tar x (sudo Pryakhin9 для read postgres datadir uid 999). 2.7G total за 8 мин.
  • Verdaccio — rsync /volume1/docker/personal/verdaccio/{storage,config,plugins} → vds:/opt/stacks/verdaccio/. 9G за 18 мин.
  • Registry — GC на kreknin (registry:2.8.3 garbage-collect -m) сжал 99G → 35G; затем user принял решение abandon миграцию и fresh install на VDS. Старый registry data остаётся на kreknin как backup-reference.

Roadmap как backup target для VDS

Планируется ежедневный pull rsync VDS → kreknin в /volume1/NetBackup/vds-kzntsv/ (см. follow-up task .tasks/vds-backup-rsync-kreknin.md). Дополнительный pipe — backup pipe для production-CMS windows-recovery-host → тут же на kreknin — пока не реализован.

Диски (инвентарь, после инцидента 2026-07-31)

Xpenology (DSM 7.1.1, apollolake) на обычном ПК-корпусе — НЕ настоящий Synology, без hot-swap лотков, диски на обычных SATA-кабелях. Урок: компрессорная продувка срывает SATA-кабели.

Диск Порт Модель Роль Статус 2026-07-31
sda ata1 WD40EFPX-68C6CN0 4TB (6682ч) md3 raid5 slot 3 жив; 213 UDMA CRC, линк упал до 1.5 Gbps = кабель
sdb — WD-WX32D12L8HTE (4TB) md3 raid5 slot 0 не определяется — отвал кабеля (питание/дата) после продувки, вероятно оживает перетыком
sdc ata3 WD40EFAX-68JH4N1 4TB SMR (30373ч) md3 raid5 slot 1 жив; WRITE FPDMA bursts 09:58/12:09 — только при ручном трясе кабелей
sdd ata4 Kingston SA400S37120G SSD (30460ч) md2 raid1 = VMM volume /volume2 восстановлен 2026-07-31

md3 = /volume1 (btrfs, бэкапы), degraded [_UU] (sdb выпал), держится на sda+sdc.

Инцидент 2026-07-31 (продувка компрессором)

Алексей продул NAS пром-компрессором → срыв SATA-кабелей:

  • sdb исчез (не определяется), md3 degraded
  • sdd DSM выкинул из md2 при загрузочной тряске (07:47) → /volume2 ушёл в ro (transient EIO)
  • sda: 213 CRC, линк 6→1.5 Gbps; sdc: bursts при трясе, без тряса стабилен

Ремонт (сделано 2026-07-31)

  • sdd/md2: DSM Storage Manager → Repair пула → sdd вернулся (но faulty active sync), затем в DSM на /volume2 кнопка «Преобразовать в чтение/запись» → rw, scrub 53GiB 0 ошибок. Урок: «Convert to read/write» в DSM снимает ro-состояние после transient EIO без mdadm-ручнины.
  • Ежедневные бэкапы на kreknin ЗАГЛУШЕНЫ (не нагружать больной массив):
    • vds-kzntsv: /etc/cron.d/vds-backup (05:00) — закомментирован, бэкап .bak.20260731
    • books-vds: /etc/cron.d/books-vds-backup (06:00) — закомментирован, бэкап .bak.20260731
    • ⚠️ ВЕРНУТЬ после починки (раскомментировать строку)

Rescue 2026-07-31 → 08-02 (полный)

USB 2TB WD20EARX (sdq) отформатирован в один btrfs, смонтирован /mnt/rescue. GNU tar --numeric-owner (хардлинки preserved; --numeric-ids — НЕ GNU-флаг, это bsdtar).

  • /mnt/rescue/netbackup/: diskstation_1.hbk.tar 430G, windows-host.tar 160G, vds-kzntsv.tar 84G, ruvds-iis.tar 62G, books-vds.tar 24G, openwrt.tar 20K
  • /mnt/rescue/userdata/: docker.tar 130G (rc=1 — файлы менялись при чтении, архив валиден), homes.tar 118G, work.tar 32G, downloads.tar 25G, documents.tar 5.9G
  • Итого 1.1TB / 726G свободно. Массив за 2 суток последовательного чтения — ноль новых ошибок.

План ремонта (осталось)

  1. Power-off (после подготовки, НЕ до слива — данные теперь спасены, риск холодного старта приемлем)
  2. Переподключить SATA: sda, sdc (свежие кабели), sdb (питание+дата)
  3. sdb определился + SMART ок → DSM Storage Manager → Repair md3 → ребилд; не определился → 4TB замена
  4. sda должен вернуться на 6 Gbps, CRC не расти
  5. Вернуть бэкапы: раскомментировать vds-backup + books-vds-backup
  6. (необязательно) sdd в md2 уже восстановлен — проверить VMM виртуалки
Reference in New Issue View Git Blame Copy Permalink