LazyVim distro로 갈아타기 — 수동 lazy.nvim 셋업을 distro에 위임하다
직접 큐레이션한 23개 플러그인 셋업을 LazyVim 15.x distro로 옮겼다. 자동으로 풀리는 것과 여전히 사용자 영역으로 남는 것, 백업·롤백·검증까지 정리한 기록.
직접 큐레이션한 23개 플러그인 셋업을 LazyVim 15.x distro로 옮겼다. 자동으로 풀리는 것과 여전히 사용자 영역으로 남는 것, 백업·롤백·검증까지 정리한 기록.
Barman 시리즈 4편 — Workbook. 보존 정책 두 가지 — REDUNDANCY n과 RECOVERY WINDOW OF n DAYS — 의 차이를 같은 lab에서 직접 적용해 본다. WAL이 backup 정책에 종속되는 핵심 원리, minimum_redundancy 안전망, barman keep으로 특정 backup을 retention에서 제외하기, OBSOLETE → DELETED 라이프사이클까지.
Barman 시리즈 5편 — Workbook. PITR target 4가지(–target-time / –target-xid / –target-name / –target-immediate)를 한 lab에서 한 번씩 직접 돌려본다. 시점을 어디로 잡을지 정하는 법(barman show-backup, pg_waldump), –target-action·–exclusive·timeline 분기, 그리고 자주 막히는 함정 5가지까지.
Barman 시리즈 3편 — Workbook. 2편의 streaming-only 모델과 짝이 되는 rsync 모델을 같은 lab에서 셋업한다. 양방향 SSH 키 분배, archive_command 설정, backup_method=rsync 전환, 그리고 reuse_backup=link 하드링크 dedup으로 디스크 사용량이 어떻게 줄어드는지 du로 직접 측정한다. 마지막에 streaming vs rsync 결정 기준.
Barman 시리즈 2편. 1편의 역사·아키텍처 위에서, 이번에는 두 대의 Rocky Linux 9 머신으로 streaming-only Barman 환경을 세운다. PostgreSQL 측·Barman 측 설정, barman check / backup / list-backup / recover / recover –target-time 5개 명령어, 그리고 cron + 보존 정책까지. 마지막에 자주 만나는 에러를 빠른 가이드로 묶었다.
pgBackRest가 멈춘 자리에 가장 자주 거론되는 대안은 Barman이다. 2008년 이탈리아 토스카나 프라토에서 문을 연 2ndQuadrant Italia에서 시작해, 2012년 Barman 1.0, 2016년 streaming 전환, 2020년 EDB의 2ndQuadrant 인수를 거쳐 14년째 활발히 유지되는 도구의 궤적을 정리한다. 아키텍처는 어떻게 생겼고, pgBackRest와는 무엇이 달랐는가.
Arc 팀이 만든 Dia를 며칠 써봤다. 디자인은 조용하고 좋다. 다만 무료로 쓰기엔 AI 한도가 짧고, 정체성도 흔들리는 중이다.
2017년에 들어간 algif_aead 인-플레이스 최적화 한 줄이 splice·AF_ALG와 만나 페이지 캐시에 임의의 4바이트를 쓰는 결정론적 LPE가 된다. Dirty COW·Dirty Pipe와 달리 race가 없고 첫 시도에 그대로 성공한다. 어제 공개된 Copy Fail의 구조와 운영자가 지금 해야 할 일.
13년 동안 한 사람이 지켜온 pgBackRest가 2026-04-27 공식적으로 유지보수 중단을 선언했다. 무슨 일이 있었는지, 다른 백업 도구(Barman, WAL-G, pg_basebackup+pg_combinebackup)는 어디까지 왔는지, CNPG는 왜 처음부터 Barman을 골랐는지, 그리고 운영자 입장에서 지금 무엇을 해야 하는지 정리한다. (2026-05-04 업데이트: 저장소 archive 해제, sponsor coalition으로 부활 진행 중 — 본문 상단 업데이트 참조.)
PostgreSQL이 process-per-connection 모델을 지킨 채 처음으로 비동기 I/O를 도입했다. sync, worker, io_uring 세 모드의 구조와 트레이드오프, 그리고 cold scan에서 io_uring이 PostgreSQL 17보다 2.7배 빨라진 이유.