워드프레스 백업 복원 전 확인할 것과 복구 순서

사이트가 열리지 않는다고 바로 오래된 백업을 덮어쓰면 최근 글과 설정까지 잃을 수 있습니다. 먼저 장애 범위와 시작 시점을 기록하고, 플러그인 오류처럼 백업 없이 해결할 수 있는지 확인하세요. 복원이 필요하다면 같은 시점의 파일과 데이터베이스를 한 쌍으로 되돌린 뒤 기능을 검증합니다.

복원 작업 전 현재 파일과 데이터베이스도 별도로 백업합니다. 고장 난 상태라도 로그, 최근 업로드나 주문처럼 과거 백업에 없는 자료를 꺼내야 할 수 있습니다. 관리자 화면, FTP·파일 관리자, 데이터베이스와 호스팅 콘솔 중 어디까지 접속되는지 기록하세요.

다음 정보도 복원 전에 모읍니다.

치명적 PHP 오류를 감지하면 WordPress가 관리자 이메일로 Recovery Mode 링크를 보낼 수 있습니다. 이 모드에서 문제를 일으킨 플러그인이나 테마를 일시 중지하고 로그인할 수 있습니다. 이메일이 오지 않았다면 호스팅 파일 관리자나 SFTP에서 의심되는 플러그인 폴더 이름을 바꾸는 방법도 있지만, 변경 전 원래 이름을 기록하세요.

플러그인 하나를 비활성화해 정상화된다면 전체 데이터베이스를 과거로 돌릴 필요가 없습니다. 반대로 파일 삭제, 데이터베이스 손상, 악성코드 감염처럼 범위가 넓다면 깨끗한 시점의 전체 백업과 호스팅 지원이 필요할 수 있습니다.

오류가 생기기 직전이면서 정상 작동을 확인한 가장 최근 백업을 고릅니다. 파일은 월요일, 데이터베이스는 수요일처럼 시점이 크게 다르면 플러그인 버전과 저장 구조가 맞지 않을 수 있습니다. 세트로 만들어진 백업을 우선하세요.

보안 사고가 의심되면 단순히 전날 자료를 고르지 말고 최초 침해 시점보다 이전인지 확인해야 합니다. 복원 뒤 취약한 계정이나 플러그인을 그대로 두면 다시 감염될 수 있으므로 원인 제거 계획도 함께 세웁니다.

호스팅의 원클릭 복원을 쓸 때도 복원 범위가 파일만인지 전체인지 확인합니다. 데이터베이스 가져오기는 현재 테이블을 대체할 수 있으므로 대상 데이터베이스가 맞는지 마지막으로 확인하세요.

정상화한 뒤 오류 원인과 복원 지점, 손실된 변경, 다시 적용한 보안 조치를 기록합니다. 다음 복원 때 필요한 시간과 누락된 계정을 알 수 있는 운영 문서가 됩니다.