Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

4.7 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

title

Backups

매 한 줄

"매 backup 은 restore 가 검증된 backup 만이다.". Backups 는 매 3-2-1 rule (3 copies, 2 media, 1 offsite) + RTO/RPO target + 정기 restore drill 의 trio. 2026 의 standard: incremental dedup (restic/borg) + immutable object lock (S3 Object Lock, Azure Immutable Blob) + ransomware-resistant air gap.

매 핵심

매 3-2-1-1-0 Rule (modern)

3 copies of data.
2 different media types.
1 offsite copy.
1 immutable / air-gapped (anti-ransomware, 매 2020+ 추가).
0 errors after restore verification.

매 RTO vs RPO

RTO (Recovery Time Objective): 매 outage 후 service 복구까지 허용 시간.
RPO (Recovery Point Objective): 매 허용 가능한 data loss window.
매 RTO=1h / RPO=15min 이면 hot standby 필요.

매 Backup Type

Full: 매 전체 — slow, large, simple restore.
Incremental: 매 since last backup — fast, smaller, restore chain.
Differential: 매 since last full — middle ground.
Snapshot (CoW): 매 ZFS/btrfs/LVM/EBS — instant, space-efficient.
Continuous (CDC): 매 every transaction — Postgres WAL, MySQL binlog.

매 응용

DB backup (pg_basebackup + WAL archive).
File backup (restic, borg, Time Machine).
VM/disk snapshot (EBS, GCP PD, ZFS).
Object store replication (S3 CRR).
App-level (export-import, logical dump).

💻 패턴

restic encrypted incremental backup

# 매 init repo (one-time)
restic init --repo s3:s3.amazonaws.com/my-backup-bucket
# 매 daily backup
restic -r s3:s3.amazonaws.com/my-backup-bucket backup /var/data \
  --exclude '*.tmp' --tag daily --host $(hostname)
# 매 retention: keep 7d, 4w, 12m
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
# 매 verify
restic check --read-data-subset=10%

Postgres PITR setup

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://pg-wal/%f'
# 매 base backup
pg_basebackup -D /backup/base -Ft -z -P -U replicator
# 매 restore: recovery.conf or postgresql.auto.conf with restore_command + recovery_target_time

S3 Object Lock (immutable, ransomware-proof)

aws s3api put-object-lock-configuration \
  --bucket my-backup-bucket \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Restore drill automation

#!/usr/bin/env bash
# 매 nightly drill — restore latest to scratch, verify checksums
set -euo pipefail
SCRATCH=$(mktemp -d)
restic -r s3:.../backup restore latest --target "$SCRATCH"
sha256sum -c expected_checksums.sha256 --strict
echo "drill ok: $(date -Iseconds)" | tee -a /var/log/restore-drill.log
rm -rf "$SCRATCH"

ZFS snapshot + send

# 매 instant CoW snapshot
zfs snapshot tank/data@$(date +%Y%m%d-%H%M)
# 매 incremental send to remote
zfs send -i tank/data@yesterday tank/data@today | ssh backup-host zfs recv tank/data

매 결정 기준

상황	Approach
Files, small-mid	restic / borg
Postgres prod	pg_basebackup + WAL archive (PITR)
MySQL prod	xtrabackup + binlog
VM	snapshot + offsite replica
Multi-cloud	S3-compatible + CRR
Compliance (WORM)	S3 Object Lock COMPLIANCE mode

기본값: 매 restic to S3 with Object Lock + nightly restore drill.

🔗 Graph

부모: SRE
변형: CI_CD_Pipeline
응용: 카오스 몽키(Chaos Monkey)
Adjacent: Secret_Management · Logging_and_Error_Handling

🤖 LLM 활용

언제: backup script generation, restore runbook drafting, log anomaly summarization. 언제 X: 매 actual restore execution — manual gate 필요.

❌ 안티패턴

No restore test: 매 가장 흔한 실패 — backup 은 되는데 restore 가 안 됨.
Single copy: 매 disk fail 한 방에 잃음.
No encryption: 매 backup 이 attack vector — at-rest encrypt 필수.
No immutability: 매 ransomware 가 backup 까지 암호화.
Forever retention: 매 비용 폭발 + GDPR 위반 가능.

🧪 검증 / 중복

Verified: restic docs; AWS Backup whitepaper; Veeam 3-2-1-1-0 guide; PostgreSQL PITR docs.
신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 3-2-1-1-0 + restic/PG PITR/S3 Object Lock

4.7 KiB Raw Blame History