해킹, 서버 장애, 실수로 인한 데이터 삭제는 어느 병원에서나 발생할 수 있습니다. 백업이 없으면 사이트가 영구히 사라지거나 복구에 며칠이 걸립니다. 병원 홈페이지 백업 관리는 사고를 예방하는 작업이 아니라, 사고 발생 시 빠른 복구를 위한 사전 준비입니다. 한 번의 사고가 백업의 가치를 증명합니다.
백업의 종류
백업은 무엇을, 얼마나 자주, 어떻게 저장하느냐에 따라 종류가 나뉩니다.
전체 백업
홈페이지 전체 파일과 데이터베이스를 한 번에 백업합니다. 복구가 단순하지만 백업 파일 크기가 크고 시간이 오래 걸립니다.
증분 백업
마지막 백업 이후 변경된 부분만 백업합니다. 저장 공간과 시간을 절약하지만 복구 시 여러 백업을 순차 적용해야 합니다.
차등 백업
최초 전체 백업 이후 변경된 부분을 누적 저장합니다. 증분보다 복구가 단순하고 전체보다 빠릅니다.
스냅샷
특정 시점의 시스템 상태를 통째로 저장합니다. 클라우드 호스팅에서 흔히 제공하며, 즉시 복구가 가능합니다.
파일·DB 일 단위 자동 백업 / 30일 이상 백업 보관 / 별도 저장소(클라우드)에 보관 / 분기 1회 복구 테스트 / 중요 변경 전 수동 백업
백업 주기와 보관
너무 자주 하면 비용이 늘고, 너무 드물게 하면 사고 시 손실이 큽니다. 균형이 필요합니다.
일 단위 자동 백업
일반적인 병원 홈페이지의 표준 주기입니다. 매일 새벽에 자동 백업이 실행되도록 설정합니다. 호스팅 업체의 기본 백업 외에 별도 백업도 권장됩니다.
실시간 백업
예약 시스템, 결제 시스템 등 데이터 변동이 잦은 경우 실시간 백업이 필요합니다. 데이터베이스 복제 기술을 활용합니다.
주간 전체 백업
일 단위 증분 백업과 별도로 주간 전체 백업을 보관합니다. 장기 복구가 필요할 때 사용됩니다.
월간 아카이브
월 1회 백업을 별도 장기 보관소에 저장합니다. 1년 이상 보관해 장기 복구나 감사에 대응합니다.
중요 변경 전 수동 백업
대규모 콘텐츠 업데이트, 디자인 변경, 기능 추가 등 중요 작업 전에는 별도 수동 백업을 추가로 진행합니다. 작업 실패 시 즉시 복구가 가능합니다.
백업 저장 위치
백업이 같은 서버에 있으면 서버 장애 시 함께 사라집니다. 분산 저장이 필수입니다.
호스팅 외부 저장
같은 호스팅 서버에 백업을 두면 호스팅 장애 시 백업도 함께 손실됩니다. 별도 클라우드 스토리지(AWS S3, 구글 드라이브, 네이버 클라우드 등)에 저장하는 것이 안전합니다.
지역 분산
대규모 재해(자연재해, 데이터센터 화재 등)를 고려해 백업을 다른 지역의 데이터센터에 저장합니다. 클라우드 서비스는 다지역 저장 옵션을 제공합니다.
로컬 백업 추가
중요 백업은 외장 하드디스크 등 오프라인 매체에도 보관할 수 있습니다. 인터넷 차단 사고에도 대응 가능합니다.
접근 권한 관리
백업 저장소의 접근 권한을 엄격히 관리합니다. 백업 자체가 해킹되면 사고가 더 커집니다. 다단계 인증, 강력한 비밀번호가 필수입니다.
복구 테스트
백업이 있어도 실제 복구가 안 되면 의미가 없습니다. 정기 테스트가 필요합니다.
분기 1회 테스트
분기마다 백업 파일로 실제 복구가 가능한지 테스트합니다. 테스트용 별도 환경에서 진행하며, 시간과 절차를 측정합니다.
복구 시간 목표(RTO)
장애 발생 후 정상 복구까지 허용 가능한 시간을 정합니다. 일반 의원은 4~8시간, 응급 진료가 있는 병원은 1~2시간이 목표입니다.
복구 지점 목표(RPO)
마지막 백업 시점에 따른 데이터 손실 허용 범위입니다. 일 단위 백업이면 최대 24시간 데이터 손실이 발생할 수 있습니다.
매뉴얼 작성
복구 절차를 매뉴얼로 작성해두면 사고 시 누구라도 즉시 대응할 수 있습니다. 담당자 부재 시에도 복구가 가능해집니다.
마무리
병원 홈페이지 백업 관리는 사고를 막는 작업이 아니라 사고 발생 시 빠른 복구를 위한 보험입니다. 일 단위 자동 백업, 외부 저장소 보관, 정기 복구 테스트의 세 가지 축이 갖춰지면 어떤 사고에도 빠른 대응이 가능합니다. 유지보수 계약에 백업과 복구 항목이 명시되어 있는지 확인하는 것이 첫 번째 점검입니다.