백업은 단순하지 않다

신뢰할 수 있는 백업은 파일을 다른 곳에 복사하는 것만으로 완성되지 않음. 장치 고장뿐 아니라 실수, 랜섬웨어, 데이터 손상에 대응하려면 과거 상태로 돌아갈 수 있어야 함 복구 시점 목표(RPO) 에 따라 스냅샷 주기를 정하고, 최근 백업은 촘촘하게, 오래된 백업은 드물게 남기는 보존 정책이 필요함 증분 백업과 중복 제거는 저장 공간과 전송 대역폭을 줄이지만, 파일 권한과 데이터베이스 일관성까지 해결하지는 못함 3-2-1 백업은 서로 다른 매체와 외부 장소로 사본을 분산함. 다만 S3 같은 객체 스토리지를 사용하면 메타데이터 보존과 작은 파일의 업로드 비용까지 고려해야 함 직접 구현하기보다 Borg나 Restic 같은 검증된 도구를 활용하고, 실제 복원을 테스트해야 함. 백업이 있어도 복원 여부를 확인하지 않으면 소용없음 사본 하나에 의존할 때 생기는 문제 가족사진을 여러 노트북과 PC에서 외장 하드 한 곳으로 옮긴 뒤, TV 셋톱박스용 저장장치로 사용하려고 포맷하면서 파일 인덱스가 지워진 사례가 있음 사진은 복구했지만, 별도 백업이 없었고 셋톱박스에도 포맷 시 데이터가 사라진다는 명확한 경고가 없었음 비기술 사용자가 포맷의 결과를 당연히 알 것으로 기대할 수는 없음 중요한 데이터를 한 곳에만 두면 고장, 도난, 장기 보관 중 데이터 손상에 취약함 하드디스크는 자성 입자의 변화로, SSD는 NAND 트랜지스터의 전하 누설로 시간이 지나며 데이터가 손상될 수 있음 첫 원칙은 다른 장소에 파일 사본을 두는 것이지만, 연결된 드라이브에는 랜섬웨어 암호화, 실수로 인한 삭제, 모든 데이터를 0으로 덮어쓰는 스크립트 실행 같은 위험도 있음 RAID 1 같은 미러링만으로는 실수 이전으로 돌아갈 수 없음. 현재 상태의 복제본이 아니라 과거 상태를 보존하는 스냅샷이 필요함 복구 시점 목표와 백업 보존 주기 복구 시점 목표(RPO, Recovery Point Objective) 는 얼마만큼의 시간에 해당하는 데이터 손실을 감수할 수 있는지에 따라 정함 가족사진은 주 1회 백업하고 6일 23시간 분량의 손실을 감수할 수도 있음 중요한 금융기관은 30초 미만, 일부 소기업은 24시간 이상을 목표로 삼으며, 재해 복구 전략 자체가 없는 곳도 있음 RPO가 24시간이면 스냅샷이 주 7개, 월 30개, 연 365개씩 쌓이므로 백업 순환 이 필요함 최근 14일치 스냅샷만 보존하면 단순하지만, 그 기간 안에 손상을 발견하지 못할 경우 문제...