Отличные решения — фиксирую:

Raw-архив только на приватной стороне. В публичный analytics сырьё не добавляем (это снимает развилку №1 и №2 — observer пишет в приватный архив, не в analytics).

Теперь сервера. Сначала загляну в репозиторий homelab (там, вероятно, инвентаризация), а параллельно подключусь по SSH ко всем трём и сниму железо/диски/нагрузку. Это read-only.

Превосходно — теперь у меня полная картина железа. И она радикально меняет разговор о модернизации. Прежде чем дать вывод, проверю реальный размер текущей продовой базы analytics — это ключевая цифра, потому что (как я покажу) узкое место не там, где вы думаете. Сначала прочитаю compose, чтобы узнать имя БД/пользователя.

БД: dicechess_analytics, пользователь dicechess_user. Запрошу реальные размеры таблиц и количество строк на проде — это даст точную экстраполяцию.

Получил реальные цифры — и они переворачивают разговор о модернизации. Вот полный разбор.

Что показало железо

	aurora (.3)	dexus (.4)	rpi4 (.9)
Класс	Ноутбук ASUS X570UD	Десктоп 2011 (Sandy Bridge)	Raspberry Pi 4
CPU	i5-8250U, 8 потоков	i5-2500, 4 ядра	Cortex-A72, 4 ядра ARM
RAM	7.6 ГБ (свободно ~194 МБ, своп 1.4 ГБ ⚠️)	3.2 ГБ ⚠️	3.7 ГБ
Диски	SSD 128 ГБ (своб. 66 ГБ) + HDD 931 ГБ (Immich) + USB-HDD 931 ГБ	2× HDD 1 ТБ, нет SSD; своб. 825 ГБ на /	SD-карта 238 ГБ (своб. 208 ГБ)
Роль	Прод analytics (PG18+API+UI) + Immich + 13 контейнеров	Staging analytics + paperless + borgbackup	Observers (dicechess+beturanga) + Cloudflare-tunnel

Картина ясная: aurora (главный сервер) — это ноутбук с маленьким SSD (66 ГБ свободно) и зажатой памятью (7.6 ГБ, уже свопит, делит ресурсы с Immich). dexus — наоборот, 825 ГБ свободного места, но на HDD и всего 3.2 ГБ RAM. rpi4 — где сидят наблюдатели и residential-IP egress для Cloudflare. Картина ясная: aurora (главный сервер) — это ноутбук с маленьким SSD (66 ГБ свободно) и зажатой памятью (7.6 ГБ, уже свопит, делит ресурсы с Immich). dexus — наоборот, 825 ГБ свободного места, но на HDD и всего 3.2 ГБ RAM. rpi4 — где сидят наблюдатели и residential-IP egress для Cloudflare.

Реальные цифры с прода (это ключ)

200 326 партий → БД analytics весит 3.47 ГБ:

Таблица	Строк	Размер	из них индексы
positions	6.18M	2402 МБ	1402 МБ
turns	3.0M	788 МБ	385 МБ
games	199k	250 МБ	26 МБ
game_events	128k	20 МБ	—

То есть ~17 КБ на партию в нормализованной БД. А raw в gzip — ~2.4 КБ на партию. Контринтуитивно, но важно: нормализованная база с индексами в ~7 раз тяжелее сжатого сырья.

Экстраполяция на ваши горизонты:

Партий	Raw-архив (gzip)	Analytics PG (нормализ.)
200k (сейчас)	~0.5 ГБ	3.5 ГБ
1M	~2.4 ГБ	~15–18 ГБ
10M (потолок)	~24 ГБ	~100–150 ГБ + RAM-bound

Вывод №1: raw-архиву модернизация НЕ нужна

Весь потолок «десятки миллионов» — это ~24 ГБ сжатого сырья. Это не big-data, это влезает куда угодно. Конкретно:

➡️ Raw-архив кладём на dexus (.4). 24 ГБ в 825 ГБ свободного HDD — это 3% диска. HDD идеально подходит: архив append-only, пишется раз, читается редко (только при реплее) — случайный IO не нужен, последовательная запись на HDD дёшева. Плюс на dexus уже крутится borgbackup → архив-источник-истины сразу под бэкапом. Ноль модернизации, ноль трат.

Реализация по приватной стороне (в публичный analytics не пишем, как вы решили): маленький сервис + SQLite (или лёгкий Postgres) на dexus; observers на rpi4 и sync POST’ят туда raw-bundle. rpi4 остаётся тонким писателем, а SD-карта (с её износом/надёжностью) не становится хранилищем истины.

Вывод №2: настоящее узкое место — нормализованная база, а не сырьё

Если вы реально идёте на 10M партий, упрётесь вот во что (по порядку наступления):

RAM на aurora (упрётесь ПЕРВЫМ). 7.6 ГБ, уже свопит, делит память с Immich. Аналитические запросы (win-rate по позициям) уже идут по 6.18M строк positions; при 50–300M строк и ~5 ГБ доступной RAM это будет тяжело disk-bound.
SSD на aurora. 66 ГБ свободно. Прод-БД пробьёт это где-то на 2–4M партий. На 10M нужно ~100–150 ГБ.

И тут проблема: aurora — это ноутбук (X570UD), потолок по RAM ~16–20 ГБ, SSD — M.2. Модернизировать можно (1 ТБ M.2 + макс. RAM), но ноутбук не лучший дом для 100–150 ГБ базы с тяжёлыми агрегациями.

dexus для самой analytics-БД не подходит (HDD = медленный random IO + 3.2 ГБ RAM), хотя для raw-архива он идеален.

Моё мнение по Oracle Cloud

Oracle Always Free Ampere A1: 4 ARM-ядра + 24 ГБ RAM + 200 ГБ block storage — бесплатно. Это решает именно тот ресурс (RAM), которого не хватает aurora, и ARM не помеха (наблюдатели уже на ARM, Postgres и Scala/JVM на ARM работают).

Но с важными границами:

✅ Подходит — для ПУБЛИЧНОЙ analytics-БД. Она source-agnostic, без реверс-инжиниринговых секретов → размещение в облаке не нарушает приватную границу. 24 ГБ RAM >> 7.6 ГБ aurora — реальный выигрыш для RAM-bound запросов.

❌ НЕ подходит — для acquisition (observers/sync/fetcher). Cloudflare требует residential IP (датацентровый IP облака ловит challenge). Это жёсткое ограничение — добыча остаётся на rpi4/homelab.

❌ НЕ кладём туда raw-архив. Это приватные реверс-инжиниринговые данные; их место — homelab (dexus), не аккаунт стороннего провайдера.

⚠️ Риски Oracle Free: (1) реклейм «простаивающих» Always Free инстансов — для системы-источника-истины держите бэкапы (borg у вас есть); (2) исторически тяжело выбить Ampere-ёмкость в free tier (out-of-capacity), хотя стало лучше. Для прода я бы либо платил (Ampere дёшев даже платно), либо принял риск с регулярными бэкапами.

Итоговая рекомендация по размещению

Слой	Где	Модернизация?
Acquisition (observers, sync, Cloudflare)	rpi4 (.9) — обязательно (residential IP)	Нет
Raw-архив (приватный, ~24 ГБ@10M)	dexus (.4) — 825 ГБ HDD + borgbackup	Нет, ноль трат
Analytics PG (публичная, ~100–150 ГБ@10M)	aurora (апгрейд) или выделенный mini-PC или Oracle Ampere	Да — но это отдельная задача

Конкретно сейчас (под 1–2M партий вам ничего не надо менять):

Поднять raw-архив на dexus, доработать observer писать в него до нормализации. Это закрывает потерю данных и даёт реплей. Без капитальных вложений.
Решение по analytics-серверу принять отдельно и только если твёрдо идёте к многомиллионному масштабу. Тогда выбор: апгрейд aurora (дёшево, но ноутбучный потолок), б/у mini-PC с 32–64 ГБ RAM + NVMe (лучший контроль, приватность, residential), или Oracle Ampere (бесплатные 24 ГБ RAM, но reclaim-риск + капасити-лотерея).

Моё личное предпочтение: под 10M-аналитику — выделенный mini-PC дома (NUC-класс, 32 ГБ, 1 ТБ NVMe — стоит недорого б/у). Держит всё локально, под residential-IP, без зависимости от облачного TOS и реклейма, и снимает Immich-конкуренцию с aurora. Oracle Ampere — хороший бесплатный план Б, если не хотите тратиться и готовы жить с бэкапами.

Главное, что я хочу донести: вы собирались модернизировать сервер ради сырья (24 ГБ) — а это как раз самая дешёвая часть, она уже помещается на dexus. Капасити-планирование нужно не сырью, а нормализованной базе — и это другой, отложенный разговор.

Хотите — распишу конкретно: (а) как поднять raw-архив-сервис на dexus + ingest-эндпоинт для observer, или (б) прикинем спеку/бюджет mini-PC vs цифры Oracle под 10M-аналитику?

Спасибо — у вас уже есть документация по железу. Читаю.

Эта документация закрывает почти все аппаратные вопросы — спасибо. Ключевое:

RAM — съёмный SO-DIMM (не распаян): сейчас 8 ГБ в одном модуле. Официально ASUS заявляет потолок 16 ГБ, но автор заметки указывает, что на 8-м поколении Intel часто заводится 32 ГБ (2×16). То есть апгрейд до 16 ГБ — гарантированно, до 32 ГБ — вероятно, но «неофициально» (зависит от числа слотов — это как раз уточнит веб-агент).
M.2 2280 слот (сейчас SATA SSD 128 ГБ) + отдельный 2.5” SATA-отсек (сейчас HDD 1 ТБ под Immich). Это важно: можно поставить 1–2 ТБ M.2-SSD под ОС+аналитику и оставить HDD в 2.5”-отсеке. Тип M.2 (SATA-only или ещё и NVMe) уточняется.
120 Вт БП, встроенный UPS (батарея). Подтверждено.
GTX 1050 спит, план — задействовать под Immich ML + транскодинг. Принципиальный вывод: ценность GPU достаётся Immich, а не аналитике — это влияет на стратегию (см. ниже, когда соберу смету).

Жду завершения ценового воркфлоу — после этого выдам обе сметы с плюсами/минусами и итоговой рекомендацией. Документ учту в синтезе.

The pricing workflow finished. Let me read the full output.

Полный расклад готов. Сначала разрешу два спорных аппаратных момента, потом — две сметы с плюсами/минусами и рекомендацией.

Что выяснилось по железу (уточнения к вашему доку)

Факт	Итог
RAM	2 слота SO-DIMM, ничего не распаяно, потолок 32 ГБ (2×16). Сейчас 1×8 ГБ, второй слот пуст. (memory-up.com, Notebookcheck K570UD — тестовый юнит с 32 ГБ.) Ваш доковый «официально 16 ГБ» — это консервативная цифра ASUS; реально 32 ГБ заводится. ⚠️ Подтвердить через `sudo dmidecode -t memory` при открытой крышке.
M.2-слот	M.2 2280, вероятно NVMe-capable (PCIe x2 Gen3 — ревью-юниты X570UD ехали с NVMe SK Hynix PC300). Сейчас в нём ваш 128 ГБ M.2 SATA SSD (HFS128G39TND — это M.2 SATA-модель). ⚠️ Поддержку NVMe именно вашего экземпляра надо проверить (вставить NVMe и посмотреть, опознается ли, либо BIOS) — есть SKU только с SATA.
2.5” отсек	Есть, занят 1 ТБ HDD (Immich).
GPU GTX 1050	Ценность — для Immich (NVENC-транскод + ML-офлоад), не для Postgres. Для БД это балласт.
Питание	Idle ~6–10 Вт (≈ €25–30/год). Батарея ~48 Вт·ч = бесплатный UPS на несколько часов graceful-shutdown.

Принципиальный вывод из этого: GPU + батарея делают aurora идеальным узлом именно для Immich/медиа/UPS — а не для аналитики. Это влияет на рекомендацию.

Вариант A — модернизация ноутбука

Цены LV, 2026-06-19 (floor агрегаторов kurpirkt/salidzini; Dateks систематически завышает — игнорирую его «потолочные» цифры).

Компонент	Что брать	Цена €
RAM до 24 ГБ	+1× Crucial 16 ГБ DDR4-2666 SO-DIMM (CT16G4SFRA266)	43–49
RAM до 32 ГБ	2×16 ГБ (заменить 8 ГБ)	86–100
SSD 1 ТБ (под БД, NVMe — если слот поддержит)	Lexar NM620 / Crucial P3 / Kingston NV2	55–90
SSD 1 ТБ (если SATA-only)	Samsung 870 EVO 2.5” (DRAM, высокий TBW)	95–105
SSD 2 ТБ (запас)	Crucial MX500 2TB	118–160

Реалистичный бюджет: €115–190 (32 ГБ + 1 ТБ NVMe ≈ €156).

Плюсы:

Дёшево, самый быстрый ROI. Сейчас машина свопит 1.4 ГБ — +RAM убирает это немедленно, заодно ускоряет Immich/Paperless.
Нулевая миграция инфраструктуры (поменял планки/диск — поехали).
Сохраняются GPU (Immich) и батарея-UPS.
~8–10 Вт — копеечное электричество.

Минусы:

Потолок 32 ГБ — жёсткий. Для аналитики на 10M партий (БД ~100–150 ГБ, RAM-bound) 32 ГБ + дележка с Immich и 13 контейнерами = впритык/мало. Хватит на 1–3M партий, не на endgame.
IO: если слот окажется SATA-only — ~550 МБ/с, не NVMe-латентность (для capacity ок, для тяжёлых агрегаций хуже).
Тонкий корпус, один вентилятор на CPU+GPU; под постоянной нагрузкой — пыль/троттлинг через месяцы; желателен undervolt.
Износ батареи при вечном 100%-заряде (можно ограничить в BIOS).
Разборка «фидлёвая» (шлейфы, частичный демонтаж платы ради второго слота/M.2).

Вариант B — mini-PC

B1. Новый (наблюдаемо на salidzini.lv, агрегирует ~105 LV-магазинов)

Модель	Конфиг	Цена €	Заметка
GMKtec M3	i5-12450H (8C/12T), 32 ГБ DDR4 (слоты!), 1 ТБ NVMe, 2.5GbE	652–700	Лучший value: сокетная RAM → апгрейд до 64 ГБ
Beelink SER5-MAX	Ryzen 7 5800H, 32 ГБ, 1 ТБ	~615	32+1ТБ в комплекте
GMKtec M5 Ultra	Ryzen 7 7730U, 32 ГБ, 1 ТБ, 2×2.5GbE	~730	Лучший AMD-комбо
Beelink SER8	Ryzen 7 8745HS, 64 ГБ DDR5, 2 ТБ	~996	No-compromise под 10M (64 ГБ сразу)
Minisforum UM690L	Ryzen 9 6900HX, 32 ГБ (LPDDR5 распаяна), 1 ТБ	~905	RAM не расширить
N100/N150 baseline	16 ГБ	306–366	❌ мало RAM для этой БД

B2. Б/у SFF/Tiny (наблюдаемо на ss.com сегодня)

Модель	Конфиг базы	База €	Доведённый до 32ГБ/1ТБ*
Lenovo M80q Tiny	i5-10500T (6C/12T), 16 ГБ, 256 ГБ NVMe	365	~500 (лучший доступный, гарантия)
HP EliteDesk 805 G8 Mini	Ryzen 5 Pro 5650G (6C/12T), 16 ГБ, 512 ГБ	409	~534 (сильный iGPU под Immich)
HP ProDesk 400 G5 Micro	i3-9100T (4C/4T ❗), 8 ГБ, 256 ГБ	190	~325 (слабый CPU)
HP EliteDesk 800 G4 SFF	i5-8500, 16 ГБ, 256 ГБ NVMe	165	~300 (но это десктоп SFF, не 1L)

апгрейд-парты: 32 ГБ kit ~€65 + 1 ТБ NVMe ~€70 = ~€135.

⚠️ Важная находка: классические дешёвые homelab-коробки (Lenovo M720q/M920q, OptiPlex Micro) сейчас на ss.lv отсутствуют — что есть, это дороже-рефурб (M80q €365). Исторически M720q/M920q (6 ядер) выходят €180–280 → доведённые €315–415; ловить понедельно по запросам thinkcentre/elitedesk/optiplex.

Плюсы mini-PC:

Решает оба узких места aurora сразу: настоящий NVMe + RAM до 64 ГБ (GMKtec M3 сокетный, или SER8 сразу 64 ГБ) — это категорически подходит под 10M-аналитику.
Выделенный хост БД: не дерётся за RAM с Immich; чище эксплуатировать.
CPU-скачок (i5-12450H/Ryzen 7 ≫ i5-8250U), 2.5GbE.
Освобождает aurora под её сильную сторону (Immich + GPU + UPS).

Минусы:

Дорого: €500–1000 против €150 за апгрейд.
Нет встроенного UPS (батареи) — нужен внешний UPS, если важен graceful-shutdown.
Нет дискретного GPU (если когда-то захотите ML на этом узле — но Immich остаётся на aurora с её 1050).
Б/у в LV сейчас «не в форме» — разрыв между доведённым б/у (~€500) и новым GMKtec M3 (€660) маленький → новый выгоднее по соотношению гарантия/64-ГБ-путь.

Электричество (Латвия)

Оба варианта дёшевы: aurora ~8–10 Вт (~€25/год), mini-PC idle ~10–20 Вт (~€30–50/год). Разница пренебрежима — не фактор решения.

Моя рекомендация: двухфазно

Решение зависит от горизонта, и обе фазы не противоречат друг другу:

Фаза 1 — сейчас, ~€90–160: апгрейд aurora (RAM до 32 ГБ + 1 ТБ SSD). Это немедленно убирает своп, обслуживает аналитику до ~1–3M партий, ускоряет Immich. Дёшево, без миграции. Перед покупкой проверьте два факта: число слотов (sudo dmidecode -t memory) и поддержку NVMe в M.2 (иначе берёте M.2 SATA / 2.5” SATA). Покупайте 870 EVO/MX500/P3 (DRAM, высокий TBW), не BX500/A400.

Фаза 2 — только когда твёрдо пойдёте на 10M: выделенный mini-PC под Postgres. Тогда aurora упрётся в свои 32 ГБ. Берите GMKtec M3 (~€660, сокетная RAM → 64 ГБ) либо Beelink SER8 (~€996, сразу 64 ГБ/2 ТБ). Postgres-аналитику переносите туда; aurora остаётся Immich-узлом с GPU и батареей-UPS. Raw-архив при любом раскладе живёт на dexus (он не требует ни того, ни другого).

Логика: GPU и батарея «привязывают» aurora к роли Immich/UPS, а жёсткий потолок 32 ГБ дисквалифицирует её для endgame-аналитики — поэтому не вливайте в ноутбук много, сделайте дешёвый апгрейд под текущий масштаб, а серьёзные деньги тратьте на mini-PC только когда реально нужен 64 ГБ.

Хотите — (а) распишу пошагово апгрейд aurora (какие планки/диск под ваш SKU + как мигрировать root/БД на новый диск без простоя), или (б) прикину, на скольких партиях именно 32 ГБ упрутся в стену (точная RAM-математика shared_buffers + рабочее множество под position-агрегации)?

Отличный подход — сначала разведка, потом покупка. Это сэкономит деньги и нервы. Давайте сделаем так: я сниму с aurora всё, что доступно по софту прямо сейчас, дам вам блок команд под sudo (их выполните вы — беспарольный sudo не настроен) и чёткий чек-лист, что именно сфотографировать при вскрытии. Сначала — мягкая разведка.

Разведка дала ещё несколько важных фактов. Вот текущая внутренняя карта aurora:

Текущая раскладка (что уже точно известно)

Слот	Накопитель	Назначение	Свободно
M.2 2280	128 ГБ M.2 SATA SSD (sdb)	EFI + `/boot` + LVM-root `/` — здесь же весь `/var/lib/docker` (БД analytics 3.5 ГБ, immich-pg, paperless-pg)	66 из 115 ГБ
2.5” SATA	1 ТБ HDD (sda)	`/mnt/immich_data` (фото Immich)	434 из 916 ГБ (занято 436)
USB 3.0	1 ТБ HDD (sdc)	`immich_backup` + бэкапы БД	—
RAM	1×8 ГБ SO-DIMM (1 из 2 слотов)	свопит 1.4 ГБ, swappiness=60	1 слот пуст
Батарея	36.3 / 48.1 Вт·ч	UPS	здоровье 75.6%

Два важных вывода из этого:

БД и фото — на разных дисках уже сейчас. Растущая часть (все Postgres-тома) сидит на маленьком 128 ГБ SSD — это и есть капасити-стена (66 ГБ → ~3–4M партий аналитики максимум).
Свободных слотов нет — и M.2, и 2.5” заняты. Чтобы добавить ёмкость, надо заменить один из накопителей, а не доставить.

Логически 128 ГБ — это именно M.2-модуль (HFS128G39TND — M.2 SATA-модель), а 1 ТБ HDD — в 2.5”-отсеке. Фото это подтвердят окончательно.

Шаг 1. Разведка ПЕРЕД покупкой

1A. Софт — выполните на aurora и пришлите вывод

sudo без пароля у вас не настроен, поэтому这 запустите сами (один блок, можно целиком):

# --- RAM: число слотов, потолок, что стоит сейчас ---
sudo dmidecode -t 16   # Physical Memory Array: Maximum Capacity + Number Of Devices (= слотов)
sudo dmidecode -t 17 | grep -E "Locator|Size|Type:|Speed|Form Factor|Manufacturer|Configured"
 
# --- здоровье обоих дисков (это решает, что можно переиспользовать) ---
sudo smartctl -a /dev/sdb | grep -iE "Model|Power_On_Hours|Percent|Wear|Reallocated|Media_Wearout|Total_LBAs_Written"
sudo smartctl -a /dev/sda | grep -iE "Model|Power_On_Hours|Reallocated|Pending|Health"
 
# --- размер каждого Postgres-тома (что будем мигрировать) ---
sudo du -sh /var/lib/docker/volumes/*/_data 2>/dev/null | sort -rh | head
 
# --- есть ли в ядре следы NVMe / режим M.2 ---
sudo dmesg | grep -iE "nvme|ahci|sata link up" | head

Что я ищу в ответе:

-t 16 → «Number Of Devices: 2» и «Maximum Capacity: 32 GB» (подтвердит 2 слота / потолок).
-t 17 → один слот с Size: 8192 MB и второй No Module Installed + Speed/Type существующей планки.
SMART sdb → Percentage_Used / Wearout 128 ГБ SSD (если износ мал — модуль можно оставить как OS-диск).

1B. BIOS (без открытия)

Перезагрузка → F2/Del → ищем:

Раздел Advanced / Onboard Devices / Storage Configuration — есть ли пункт про M.2 / NVMe / PCIe storage mode. Если BIOS вообще упоминает NVMe для M.2 — слот комбинированный (хорошо).
Boot order — запомнить (после замены диска может слететь).
Есть ли Battery Health Charging / charge limit (ASUS иногда прячет; ограничение до ~80% продлит жизнь батареи-UPS, сейчас 75.6%).
Версия BIOS у вас X570UD.311 (2019) — обновлять не нужно для апгрейда.

1C. Фото при вскрытии — чек-лист

⚠️ Сначала: выключить → отключить адаптер → отсоединить шлейф внутренней батареи от платы (обязательно перед работой с RAM/SSD) → антистатика. По отзывам Notebookcheck, до второго слота RAM / M.2 может потребоваться частичный демонтаж платы — снимайте не торопясь, фотографируйте каждый шаг.

Сфотографировать (и что это даёт):

Фото	Что покажет / зачем
Оба слота RAM крупно	подтвердит 2 слота и что 1 пуст; наклейку модуля (частота/вольтаж)
M.2-разъём с накопителем и без (вынуть 128 ГБ)	ключ разъёма: один вырез ближе к краю (M-key) ⇒ PCIe/NVMe-способен; два выреза (B+M) ⇒ обычно SATA/x2. Плюс шёлкография рядом («SATA3 / PCIE», «NGFF»)
Этикетка 128 ГБ модуля	форм-фактор (2280) и что это именно M.2 SATA
2.5”-отсек (салазки/шлейф)	подтвердит, что там 1 ТБ HDD и тип подключения
Радиатор/вентилятор + общий вид	оценить охлаждение под 24/7 и запылённость
Регуляторная наклейка (низ корпуса)	точная модель/ревизия

Эмпирический тест NVMe (самый надёжный): купите 1 ТБ NVMe в магазине с возвратом, вставьте, загрузитесь → lsblk/sudo nvme list. Опознался — слот комбинированный, берёте NVMe. Нет — возвращаете, идёте по SATA-пути.

Шаг 2. Что покупать (дерево решений)

RAM — однозначно, главный рычаг

Спецификация: DDR4 SO-DIMM, 260-pin, 1.2 В, non-ECC, 2666 CL19 (i5-8250U максимум 2400 — 2666/3200 просто снизят частоту, это нормально).
До 32 ГБ (рекомендую): 2×16 ГБ — заменить 8 ГБ. ~€86–100 (Crucial CT16G4SFRA266 ~€43/шт). Полноценный dual-channel.
До 24 ГБ (бюджетно): +1×16 ГБ к существующим 8. ~€43. Асимметрично, но работает.
Не б/у: новая планка дешевле подержанной SK Hynix (€75).

Накопитель — зависит от итога по NVMe

Если M.2 поддерживает NVMe (подтвердили фото/BIOS/тестом) → План N (дешевле и быстрее):

1 ТБ NVMe Gen3, с DRAM/нормальным TBW: Crucial P3 / WD SN580 / Lexar NM620 — ~€55–90.
Заменяет 128 ГБ M.2; OS+все БД переезжают на быстрый диск; Immich остаётся на HDD.

Если M.2 только SATA → План S (надёжнее, без клонирования и гаданий):

2 ТБ 2.5” SATA SSD с DRAM: Crucial MX500 2 ТБ ~€140 (или 1 ТБ 870 EVO ~€95, если хватит).
Заменяет 1 ТБ HDD в 2.5”-отсеке; на него переезжают /var/lib/docker и /mnt/immich_data; 128 ГБ M.2 остаётся чистой OS; старый HDD → запасной бэкап.

Чего не брать для БД с WAL: Crucial BX500 / Kingston A400 / QLC без DRAM — низкий TBW.

Шаг 3. Миграция (без потери данных)

Сначала — страховка (оба плана):

# дамп аналитики на USB-бэкап-диск
sudo docker exec dicechess-analytics-db-1 pg_dump -U dicechess_user -Fc dicechess_analytics \
  > /mnt/immich_backup/analytics_$(date +%F).dump
# остановить стеки перед копированием томов
cd /path/to/each/compose && sudo docker compose down   # для каждого стека

План N (NVMe, замена M.2 + клон root)

Понадобится USB-M.2 NVMe-бокс (~€15) для подключения нового диска во время клонирования.

# 1. Новый NVMe в USB-боксе → допустим он /dev/sdX (проверьте lsblk!)
# 2. Клон всего диска (EFI+boot+LVM). Безопаснее всего Clonezilla (disk-to-disk).
#    Альтернатива live-dd (стеки остановлены):
sudo dd if=/dev/sdb of=/dev/sdX bs=64M conv=fsync status=progress
# 3. Выключить → вынуть 128 ГБ M.2 → вставить NVMe в M.2-слот → загрузиться
#    (fstab на UUID/LVM, поэтому загрузится; NVMe станет /dev/nvme0n1)
# 4. Расширить LVM на весь объём:
sudo growpart /dev/nvme0n1 3
sudo pvresize /dev/nvme0n1p3
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
df -h /              # должно стать ~1 ТБ

Итог: OS + все БД на быстром NVMe (1 ТБ), фото Immich остаются на HDD. Минимум перемещений.

План S (SATA, замена HDD — без клонирования root, ниже риск)

# 1. Новый 2 ТБ SSD ставим в 2.5"-отсек вместо HDD (HDD пока в USB-бокс для переноса)
sudo mkfs.ext4 -L data2tb /dev/sdX1        # разметить новый SSD
sudo mkdir -p /mnt/data2tb && sudo mount /dev/sdX1 /mnt/data2tb
# 2. Перенести фото Immich и все docker-тома (стеки остановлены):
sudo rsync -aHAX --info=progress2 /mnt/immich_data/ /mnt/data2tb/immich_data/
sudo rsync -aHAX --info=progress2 /var/lib/docker/  /mnt/data2tb/docker/
# 3. Переключить docker на новый data-root и перемонтировать immich:
#    /etc/docker/daemon.json -> {"data-root":"/mnt/data2tb/docker"}
#    /etc/fstab: immich_data -> /mnt/data2tb/immich_data (или bind-mount)
sudo systemctl restart docker
# 4. Поднять стеки, проверить БД. Старый HDD -> доп. бэкап.

Итог: тяжёлое (фото + все БД) на 2 ТБ SSD, OS на надёжном 128 ГБ M.2, без клонирования и без NVMe-гадания.

Шаг 4. После апгрейда — настройка (ради этого всё и затевалось)

# 1. Убрать агрессивный своп (теперь RAM много)
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swap.conf && sudo sysctl --system
# 2. TRIM для SSD
sudo systemctl enable --now fstrim.timer

PostgreSQL analytics делит 32 ГБ с Immich-pg, paperless-pg и Immich-ML — нельзя отдать ему всё. Стартовый бюджет для контейнера analytics (postgres:18):

shared_buffers = 6GB
effective_cache_size = 14GB
work_mem = 64MB (осторожно — на коннект; ваши агрегации по позициям любят память, но при многих коннектах суммируется)
maintenance_work_mem = 1GB
плюс memory-лимиты в compose для Immich-ML/тяжёлых контейнеров, чтобы они не выбили БД в OOM.

Точные цифры подберём отдельно — это зависит от того, сколько RAM реально оставлять под page cache при работающем Immich.

Риски и аккуратность

Батарея: перед работой отсоединить её шлейф. Здоровье 75.6% — для UPS ок; если в BIOS есть charge-limit, поставьте ~80%.
Разборка фидлёвая (шлейфы, возможен частичный демонтаж платы ради 2-го слота/M.2) — фото на каждом шаге.
NVMe-гамбл: если не уверены — берите возвратный или сразу идите по Плану S.
После замены диска проверьте boot order в BIOS.
Имена устройств в командах (sdb/sdX/nvme0n1) сверяйте по lsblk — не вслепую.

Жду вывод sudo-блока (1A) и, если вскроете, — фото по чек-листу (1C). По ним я: (а) окончательно подтвержу RAM-потолок и NVMe, (б) выберу План N или S под ваш экземпляр, (в) дам точные команды миграции уже с реальными именами устройств.

И отдельно: хотите, обновлю ваш homelab/docs/.../asus-x570ud.md исправленными фактами (2 слота / 32 ГБ, батарея 75.6%, статус NVMe), чтобы док не вводил в заблуждение в следующий раз?

Dice Chess Wiki

Explorer

2026-06-19