Viktor Barzin d6590612b2 immich: bulk-import Anca's Elements photo archive into her account

Grows pve/nfs-data 3T → 4T (online lvextend + resize2fs) to absorb ~340 GB
of new originals landing under /srv/nfs/immich/upload during the import.

Adds:
- module "nfs_anca_elements_host" — RO PVC over /srv/nfs/anca-elements,
  consumed only by the import Job (not mounted in immich-server).
- kubernetes_job_v1.anca_elements_import — immich-go v0.31.0 uploader
  posting to immich-server.immich.svc:2283 with Anca's API key (synced
  via the existing immich-secrets ExternalSecret from
  secret/immich.anca_api_key). Filters to image extensions, bans the
  non-photo top-level dirs (filme/, Music/, carti/, courses, installers,
  docs, etc.), puts every asset in the album "Poze (Elements)". Default
  `--pause-immich-jobs` is disabled — non-admin keys can't pause jobs.
- docs/architecture/storage.md — note the new 4 TB size in 3 places.
- docs/runbooks/grow-pve-nfs-lv.md — captures the one-shot lvextend
  procedure (no pve-host TF stack exists for this).

Job is removed in the follow-up cleanup commit once the upload completes;
the PVC stays for a videos batch later.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-24 14:12:30 +00:00

2 KiB

Raw Blame History

Runbook: Grow `/srv/nfs` LV (`pve/nfs-data`)

Use when /srv/nfs on the PVE host is filling up and the workloads writing to it cannot be slimmed down. The LV sits on the LVM-thin pool pve/data (10.54 TB total). Thin-pool free space is the real gate — confirm before extending.

When to use

df -h /srv/nfs shows usage > ~85 % and projected growth exceeds free space within a backup retention window.
An upcoming bulk write (media import, restore) needs headroom that the current free space won't absorb.

Steps

Check thin-pool headroom on PVE host:
```
ssh root@192.168.1.127 'lvs pve/data; lvs pve/nfs-data; df -h /srv/nfs'
```
The pve/data thin pool's Data% should leave room for the extension (target Data% after extend < 90 %).
Extend the LV and online-resize ext4:
```
ssh root@192.168.1.127 '
  lvextend -L +1T pve/nfs-data &&
  resize2fs /dev/pve/nfs-data
'
```
Both commands are safe online: lvextend only grows allocation, resize2fs extends ext4 while mounted.
Verify:
```
ssh root@192.168.1.127 'lvs pve/nfs-data; df -h /srv/nfs'
```
df should show the new size; Use% should drop proportionally.

Notes

Not Terraform-managed. PVE host LVs live outside the IaC tree (no infra/stacks/pve-host/). Record the new size in docs/architecture/storage.md (the "HDD NFS" line and the diagram label) in the same commit.
Thin-pool overcommit warning from lvextend is informational — it reports the sum of all thin volume virtual sizes (currently ~12 TiB) vs. the physical pool (10.7 TiB). Real fill is pve/data Data%; ignore the overcommit warning unless Data% itself is climbing toward 100 %.
/srv/nfs-ssd lives on a separate LV (ssd/nfs-ssd-data) backed by SSDs — the same lvextend/resize2fs pattern applies, but the source pool is ssd/data.

Backout

Online shrinks are unsafe with active workloads. Don't try to shrink pve/nfs-data in place — restore from snapshot or migrate data out and rebuild the LV instead.

2 KiB Raw Blame History

Runbook: Grow /srv/nfs LV (pve/nfs-data)