sudo rm -rf /

// 교훈을 코드로
const lessons = {
  '백업을 했는가': false,        // 했다고 생각했음
  '백업을 확인했는가': false,    // 안 했음
  '백업에서 복구 테스트를 했는가': false,  // 당연히 안 했음
  '출산휴가 직원에게 감사했는가': true,     // 했겠지...
};

// "백업은 확인하기 전까지는 백업이 아니다"

# 엔지니어가 실행하려던 것
# 스테이징 DB의 디렉토리를 삭제

# 실제로 실행한 것
sudo rm -rf /var/lib/postgresql/data/  # 프로덕션 DB 디렉토리
# 터미널 창을 잘못 골랐음

// 실제로 일어난 일을 간략화하면

// 의도: 소규모 서버 그룹 제거
const serversToRemove = 'billing-subsystem-small-group';

// 실수: 더 큰 범위의 서버 그룹을 지정
const serversToRemove = 'billing-subsystem';  // 전체 빌링 서브시스템

// 이 빌링 서브시스템이 S3의 다른 핵심 서브시스템에 의존되어 있었고
// 도미노처럼 무너져서 S3 전체가 장애

# 실제로 일어난 rm -rf 변형 사고들

# Case 1: 변수가 비어있을 때
BUILD_DIR=""
rm -rf $BUILD_DIR/*
# $BUILD_DIR이 비어있으면?
# rm -rf /*  ← 루트 전체 삭제!

# Case 2: 공백이 포함된 경로
rm -rf /home/user/My Documents/old files/
# 실제로 실행되는 것:
# rm -rf /home/user/My
# rm -rf Documents/old
# rm -rf files/
# → 3개의 별개 경로를 삭제 시도

# Case 3: 스크립트에서의 실수
#!/bin/bash
cd $DEPLOY_DIR || exit 1
rm -rf *
# DEPLOY_DIR이 설정 안 되어 있으면?
# cd 실패 → exit... 인데 || 을 && 로 잘못 쓰면?
# cd 실패해도 현재 디렉토리에서 rm -rf * 실행

// rm이 실제로 하는 일 (간략화)

// rm은 파일의 데이터를 지우지 않음
// inode의 링크 카운트를 줄이는 것뿐

interface Inode {
  data_blocks: number[];    // 실제 데이터 위치
  link_count: number;       // 이 파일을 가리키는 경로 수
  permissions: string;
  owner: number;
  size: number;
}

function rm(filepath: string): void {
  const inode = getInode(filepath);
  inode.link_count--;

  // 디렉토리 엔트리에서 제거
  removeDirectoryEntry(filepath);

  if (inode.link_count === 0) {
    // 링크가 하나도 없으면 데이터 블록을 "사용 가능"으로 표시
    // 데이터 자체는 아직 디스크에 있음!
    markBlocksAsFree(inode.data_blocks);
  }
}

// 이래서 데이터 복구가 가능한 거임
// 파일을 "삭제"해도 디스크의 데이터는 덮어씌워지기 전까지 남아있음
// 하지만 rm -rf로 대량 삭제하면 새 파일이 기존 블록을 덮어쓸 확률이 높아짐
// → 삭제 후 시간이 지날수록 복구 확률 급감

# 보호 장치 1: --preserve-root (GNU coreutils 6.4+, 2006~)
rm -rf /
# rm: it is dangerous to operate recursively on '/'
# rm: use --no-preserve-root to override this failsafe
# → 기본적으로 / 삭제 차단

# 보호 장치 2: alias
# ~/.bashrc에 추가
alias rm='rm -i'  # 항상 확인 물어봄
# 근데 이러면 rm -rf가 귀찮아져서 결국 rm -rf로 직접 호출하게 됨
# → 의미 없음

# 보호 장치 3: safe-rm 패키지
# /etc/safe-rm.conf에 보호할 경로 목록
# /, /etc, /usr, /var 등을 삭제하려고 하면 차단

# 보호 장치 4: 휴지통 사용
# trash-cli 패키지
trash-put file.txt  # 삭제 대신 휴지통으로
trash-list          # 휴지통 목록
trash-restore       # 복구

#!/bin/bash
# deploy.sh — 이 스크립트에 버그가 있음

APP_DIR="/var/www/myapp"
BACKUP_DIR="/var/backup/myapp-$(date +%Y%m%d)"

echo "백업 시작..."
cp -r $APP_DIR $BACKUP_DIR

echo "기존 파일 정리..."
rm -rf $APP_DIR/*

echo "새 버전 배포..."
cp -r /tmp/build/* $APP_DIR/

echo "배포 완료!"

// 이 스크립트의 문제점:

// 1. APP_DIR이 설정 안 되면?
// rm -rf /* → 루트 전체 삭제

// 2. cp 백업이 실패해도 rm이 실행됨
// 디스크 공간 부족으로 백업 실패 → 원본도 삭제 → 전부 날아감

// 3. /tmp/build/가 비어있으면?
// 기존 파일 삭제 + 빈 디렉토리 복사 = 빈 서버

// 안전한 버전

#!/bin/bash
set -euo pipefail  # 에러 시 즉시 중단, 미설정 변수 에러, 파이프 에러

APP_DIR="${APP_DIR:?APP_DIR 환경변수가 설정되지 않음}"
BACKUP_DIR="/var/backup/myapp-$(date +%Y%m%d)"
BUILD_DIR="/tmp/build"

# 디렉토리 존재 확인
if [ ! -d "$APP_DIR" ]; then
  echo "ERROR: $APP_DIR 디렉토리가 없음"
  exit 1
fi

if [ ! -d "$BUILD_DIR" ] || [ -z "$(ls -A $BUILD_DIR)" ]; then
  echo "ERROR: 빌드 디렉토리가 없거나 비어있음"
  exit 1
fi

echo "백업 시작..."
cp -r "$APP_DIR" "$BACKUP_DIR" || { echo "백업 실패!"; exit 1; }

echo "기존 파일 정리..."
rm -rf "${APP_DIR:?}"/*

echo "새 버전 배포..."
cp -r "$BUILD_DIR"/* "$APP_DIR"/

echo "배포 완료!"

# 30일 이상 된 로그 파일 삭제 크론잡
0 3 * * * find /var/log/myapp -name "*.log" -mtime +30 -delete

# 6개월 후, 누군가 로그 경로를 변경함
# /var/log/myapp → /var/log/services/myapp
# 크론잡은 업데이트 안 함

# 그 후 누군가 /var/log/myapp에 심볼릭 링크를 만듦
# ln -s /var/log /var/log/myapp
# → 크론잡이 /var/log 전체에서 30일 이상 된 로그를 삭제
# → 시스템 로그까지 날아감

// "잠깐 테스트용 데이터 좀 지우려고요"

// 의도: 테스트 계정 삭제
const deleteTestUsers = async () => {
  await db.query('DELETE FROM users WHERE email LIKE "%@test.com"');
};

// 실수 1: 프로덕션 DB에 연결됨
// .env에 DATABASE_URL이 프로덕션을 가리키고 있었음

// 실수 2: WHERE 절 빼먹음
const deleteTestUsers = async () => {
  await db.query('DELETE FROM users');  // WHERE 없음 = 전체 삭제
};

// 실수 3: CASCADE
// users 테이블에 CASCADE가 걸려있으면?
// users 삭제 → orders 삭제 → payments 삭제 → invoices 삭제
// 도미노처럼 관련 테이블 전부 날아감

-- CASCADE의 공포
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id) ON DELETE CASCADE,
  -- user 삭제되면 order도 삭제됨
  total DECIMAL(10, 2)
);

CREATE TABLE payments (
  id SERIAL PRIMARY KEY,
  order_id INTEGER REFERENCES orders(id) ON DELETE CASCADE,
  -- order 삭제되면 payment도 삭제됨
  amount DECIMAL(10, 2)
);

-- DELETE FROM users; 한 줄이면
-- users + orders + payments 전부 날아감

// 백업의 황금률: 3-2-1

const backupStrategy = {
  copies: 3,        // 최소 3개의 복사본
  media: 2,         // 최소 2개의 다른 저장 매체 (SSD + 클라우드 등)
  offsite: 1,       // 최소 1개는 물리적으로 다른 장소에

  // 추가 규칙
  tested: true,     // 복구 테스트를 했는가?
  automated: true,  // 자동화되어 있는가?
  monitored: true,  // 백업 실패 시 알림이 오는가?
};

# PostgreSQL 백업 방법들

# 1. pg_dump — 논리적 백업
pg_dump -h localhost -U postgres mydb > backup_$(date +%Y%m%d_%H%M%S).sql
# 장점: 사람이 읽을 수 있음, 특정 테이블만 복구 가능
# 단점: 대용량 DB에서 느림, 복원도 느림

# 2. pg_basebackup — 물리적 백업
pg_basebackup -h localhost -D /backup/base -Fp -Xs -P
# 장점: 빠름, Point-in-Time Recovery 가능
# 단점: 같은 PostgreSQL 버전에서만 복원 가능

# 3. WAL 아카이빙 — 연속 백업
# postgresql.conf
# archive_mode = on
# archive_command = 'cp %p /archive/%f'
# → 모든 변경사항을 WAL 파일로 기록
# → 특정 시점으로 복구 가능 (PITR)

// 자동 백업 스크립트 (Node.js)
import { execFileSync } from 'child_process';
import { existsSync, statSync } from 'fs';

interface BackupResult {
  success: boolean;
  path: string;
  size: number;
  timestamp: Date;
}

function createBackup(dbName: string): BackupResult {
  const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
  const backupPath = `/backup/${dbName}_${timestamp}.sql.gz`;

  try {
    // pg_dump + gzip 압축
    execFileSync('bash', [
      '-c',
      `pg_dump -h localhost -U postgres ${dbName} | gzip > ${backupPath}`
    ]);

    // 백업 파일 검증
    if (!existsSync(backupPath)) {
      throw new Error('백업 파일이 생성되지 않음');
    }

    const stats = statSync(backupPath);
    if (stats.size < 1000) {
      throw new Error('백업 파일이 너무 작음 — 비어있을 가능성');
    }

    return {
      success: true,
      path: backupPath,
      size: stats.size,
      timestamp: new Date(),
    };
  } catch (error) {
    // 알림 발송
    sendAlert(`백업 실패: ${dbName} — ${error}`);
    return {
      success: false,
      path: backupPath,
      size: 0,
      timestamp: new Date(),
    };
  }
}

// 백업을 했다고 안심하면 안 됨
// 복구가 되는지 확인해야 함

async function testBackupRestore(backupPath: string): Promise<boolean> {
  const testDbName = `restore_test_${Date.now()}`;

  try {
    // 1. 테스트 DB 생성
    await execCommand(`createdb ${testDbName}`);

    // 2. 백업에서 복원
    await execCommand(`gunzip -c ${backupPath} | psql ${testDbName}`);

    // 3. 데이터 무결성 확인
    const userCount = await query(testDbName, 'SELECT COUNT(*) FROM users');
    const orderCount = await query(testDbName, 'SELECT COUNT(*) FROM orders');

    console.log(`복원 결과: users=${userCount}, orders=${orderCount}`);

    // 4. 기본적인 쿼리 실행 확인
    await query(testDbName, 'SELECT * FROM users LIMIT 1');
    await query(testDbName, 'SELECT * FROM orders LIMIT 1');

    console.log('백업 복구 테스트 성공!');
    return true;
  } catch (error) {
    console.error(`백업 복구 테스트 실패: ${error}`);
    sendAlert(`백업 복구 테스트 실패! ${backupPath}`);
    return false;
  } finally {
    // 테스트 DB 정리
    await execCommand(`dropdb ${testDbName}`);
  }
}

// 이 테스트를 주간 크론잡으로 실행
// 실패하면 즉시 알림 → 백업이 무용지물이 되기 전에 고칠 수 있음

// 하드 삭제 대신 소프트 삭제

// 나쁜 예: 실제 삭제
async function deleteUser(userId: number): Promise<void> {
  await db.query('DELETE FROM users WHERE id = $1', [userId]);
  // 돌이킬 수 없음
}

// 좋은 예: 소프트 삭제
interface User {
  id: number;
  name: string;
  email: string;
  deletedAt: Date | null;  // null이면 활성, 날짜가 있으면 삭제됨
}

async function softDeleteUser(userId: number): Promise<void> {
  await db.query(
    'UPDATE users SET deleted_at = NOW() WHERE id = $1',
    [userId]
  );
  // 복구 가능: UPDATE users SET deleted_at = NULL WHERE id = $1
}

// 조회 시 삭제된 유저 제외
async function getActiveUsers(): Promise<User[]> {
  return db.query('SELECT * FROM users WHERE deleted_at IS NULL');
}

// 관리자용: 삭제된 유저도 포함
async function getAllUsers(): Promise<User[]> {
  return db.query('SELECT * FROM users');
}

// 실제 삭제는 30일 후 배치로 처리
async function purgeDeletedUsers(): Promise<void> {
  await db.query(
    "DELETE FROM users WHERE deleted_at < NOW() - INTERVAL '30 days'"
  );
}

// 위험한 작업 전 확인 절차

interface DangerousAction {
  type: 'delete' | 'drop' | 'truncate';
  target: string;
  affectedRows: number;
}

async function confirmDangerousAction(action: DangerousAction): Promise<boolean> {
  // 1. 영향 범위 표시
  console.log(`위험한 작업: ${action.type} ${action.target}`);
  console.log(`영향받는 행: ${action.affectedRows}개`);

  // 2. 임계값 체크
  if (action.affectedRows > 1000) {
    console.log('경고: 1000개 이상의 행이 영향받음');
    console.log('정말 실행하시겠습니까?');

    // 3. 타겟 이름 직접 입력 확인 (GitHub 스타일)
    const confirmation = await prompt(
      `확인하려면 "${action.target}"을 입력하세요:`
    );

    if (confirmation !== action.target) {
      console.log('작업 취소됨');
      return false;
    }
  }

  return true;
}

// GitHub의 위험한 설정 패턴을 차용
// "저장소를 삭제하려면 'owner/repo-name'을 입력하세요"
// 이 패턴이 실수를 잡아주는 횟수가 생각보다 많음

// Terraform의 prevent_destroy

// main.tf (Terraform)
// resource "aws_db_instance" "production" {
//   identifier = "prod-database"
//   engine     = "postgres"
//
//   lifecycle {
//     prevent_destroy = true
//     # terraform destroy를 실행해도 이 리소스는 삭제 안 됨
//     # 삭제하려면 이 설정을 먼저 제거해야 함
//   }
// }

// 코드로 인프라를 관리하면:
// 1. "누가 이 서버 지웠어?" → git blame으로 확인 가능
// 2. 실수로 삭제 → PR 리뷰에서 잡힘
// 3. prevent_destroy로 중요 리소스 보호

// 삭제 사고 발생 시 행동 매뉴얼

const incidentResponse = {
  step1_dontPanic: '침착하게. 추가 조치를 하기 전에 상황 파악.',

  step2_stopBleeding: '추가 피해 방지. 서버 접근 차단, 디스크 쓰기 중지.',
  // 삭제된 데이터는 덮어씌워지기 전까지 복구 가능
  // 새로운 쓰기를 막는 게 급선무

  step3_assess: '피해 범위 파악. 뭐가 날아갔는지 확인.',

  step4_communicate: '팀에 알리기. 혼자 해결하려고 하지 말 것.',
  // "실수를 숨기면 작은 사고가 큰 사고가 됨"

  step5_recover: '복구 시작. 백업에서 복원 또는 다른 방법 시도.',

  step6_postmortem: '사후 분석. 왜 일어났는지, 어떻게 방지할 건지.',
  // Blame-free postmortem — 사람을 탓하지 말고 시스템을 개선
};