시놀로지 NAS에서 워드프레스 백업은 성공했는데 왜 복구가 안 되나요?

백업 프로그램이 성공으로 표시하는 것은 데이터를 정해진 위치에 기록했다는 의미일 뿐, 실제 사이트 구동에 필요한 파일 무결성, 데이터베이스 일치 여부, PHP 버전, 파일 권한, 도메인 환경 등이 복구 환경과 완벽히 일치하지 않으면 복구에 실패할 수 있습니다.

워드프레스 복구 성공을 위해 확인해야 할 요소는 무엇인가요?

필요한 모든 파일의 포함 여부, 올바른 데이터베이스 백업 여부, 파일과 DB 생성 시점의 일치, 백업 파일의 손상 여부, 암호화 키 보관, 새 환경에서의 호환성(PHP 및 플러그인 버전), 그리고 올바른 복구 절차 수행 여부를 확인해야 합니다.

복구 후 워드프레스 새 설치 화면이 나타나는 이유는 무엇인가요?

복구 후 새 설치 화면이 나타난다면 데이터베이스 연결 설정이 잘못되었거나, 백업된 데이터베이스 이름과 현재 연결된 데이터베이스 정보가 일치하지 않을 가능성이 높습니다.

시놀로지 NAS 워드프레스 백업은 있는데 복구가 안 되는 이유, 복원 실패 원인 찾기

IT왕세자 2026년 9월 26일 최종 수정 9월 14일 읽는 시간 약 29분

시놀로지 NAS에 워드프레스 백업 파일을 보관하고 있어도 실제 장애가 발생했을 때 복구되지 않는 경우가 있습니다.

백업 작업에는 성공이라고 표시되고 압축 파일도 정상적으로 존재하지만, 복원 후 사이트에 접속하면 데이터베이스 연결 오류가 나타나거나 새 워드프레스 설치 화면이 열릴 수 있습니다.

사이트는 열리지만 게시글이나 이미지가 없고, 관리자 로그인이 되지 않거나 화면 디자인이 깨지는 경우도 있습니다.

이런 문제가 발생하는 가장 큰 이유는 백업 파일이 존재하는 것과 워드프레스 사이트를 복구할 수 있는 것은 다르기 때문입니다.

워드프레스는 사이트 파일과 MariaDB 데이터베이스가 함께 작동합니다. 여기에 PHP 버전, 데이터베이스 계정, Web Station 문서 루트, 파일 권한, 도메인과 HTTPS 환경까지 맞아야 실제 사이트가 복원됩니다.

따라서 복구가 실패했을 때 백업 파일부터 다시 만들기보다 어느 단계에서 복원이 멈췄는지 구분해야 합니다.

백업 성공과 복구 성공은 다른 결과다

백업 프로그램에서 성공으로 표시되는 것은 정해진 데이터를 대상 위치에 기록했다는 의미에 가깝습니다.

다음 내용까지 자동으로 보장하지는 않습니다.

필요한 파일이 모두 포함되었는가
올바른 데이터베이스를 백업했는가
파일과 DB의 생성 시점이 일치하는가
백업 파일이 손상되지 않았는가
암호화 키를 보관하고 있는가
새 환경에서 파일을 읽을 수 있는가
실제로 MariaDB에 가져올 수 있는가
PHP와 플러그인 버전이 호환되는가
복구 절차를 알고 있는가
복구 후 관리자 로그인이 가능한가

백업의 최종 기준은 파일이 만들어졌는지가 아니라 원하는 시점의 사이트를 실제로 다시 실행할 수 있는지입니다.

먼저 복구 실패 증상을 구분한다

복구 후 어떤 화면이 나타나는지에 따라 원인 범위를 줄일 수 있습니다.

복구 후 증상	우선 확인할 원인
워드프레스 새 설치 화면 표시	DB 연결, DB 이름, 테이블 접두사
데이터베이스 연결 오류	MariaDB, 계정, 비밀번호, DB 호스트
메인 화면은 열리지만 글이 없음	잘못된 DB 또는 불완전한 DB 복원
글은 있지만 이미지가 안 보임	uploads 누락, URL, 권한
화면이 흰색으로 표시됨	PHP, 플러그인, 테마 호환성
500 Internal Server Error	PHP 확장, 권한, 설정 파일
관리자 로그인이 안 됨	사이트 URL, 쿠키, DB 사용자 데이터
사이트가 다른 주소로 이동	DB의 `home`과 `siteurl`
게시물만 404 오류	고유주소와 재작성 규칙
디자인이 깨짐	테마 파일, CSS 캐시, 플러그인
일부 게시글만 사라짐	파일·DB 백업 시점 불일치
Hyper Backup 백업을 열 수 없음	백업 저장소, 인덱스, 암호화 정보
복원 중 작업이 중단됨	용량, 메모리, 파일 손상, 시간 초과

같은 복구 실패라도 새 설치 화면과 흰 화면은 확인해야 할 원인이 다릅니다.

워드프레스 복구에 필요한 백업은 두 가지다

워드프레스 사이트를 복구하려면 일반적으로 파일과 데이터베이스가 모두 필요합니다.

워드프레스 파일에 저장되는 데이터

워드프레스 코어
테마
플러그인
업로드 이미지
사용자 정의 코드
wp-config.php
.htaccess
인증 및 확인용 파일
일부 플러그인 데이터

MariaDB 데이터베이스에 저장되는 데이터

게시글과 페이지
사용자 계정
댓글
메뉴
카테고리와 태그
사이트 주소
워드프레스 설정
플러그인 설정
테마 설정
사용자 권한
예약 작업 정보

파일만 복원하면 게시글과 설정이 돌아오지 않습니다.

DB만 복원하면 글은 존재하지만 테마, 플러그인과 업로드 이미지가 없을 수 있습니다.

1단계: 백업 안에 무엇이 들어 있는지 확인한다

백업 파일 이름이나 작업 이름만 보고 전체 사이트 백업이라고 판단하면 안 됩니다.

다음 항목이 실제로 포함됐는지 확인합니다.

워드프레스 설치 폴더
wp-content
wp-content/uploads
사용 중인 테마
활성 플러그인
wp-config.php
.htaccess
MariaDB 내보내기 파일
데이터베이스의 모든 워드프레스 테이블
별도 경로에 저장된 사용자 파일

DB 백업 파일의 대표적인 형태

wordpress.sql
wordpress.sql.gz
wordpress.sql.bz2

백업 폴더 안에 이런 파일이 없다고 해서 DB 백업이 반드시 누락됐다고 단정할 수는 없습니다. Hyper Backup이나 백업 플러그인이 자체 형식 안에 DB를 포함할 수도 있기 때문입니다.

반대로 .sql 파일이 있다고 해서 올바른 워드프레스 DB라고 단정해서도 안 됩니다.

파일을 열어 워드프레스 테이블 구조와 데이터가 실제로 들어 있는지 확인해야 합니다.

2단계: 백업 파일과 DB의 시점이 같은지 확인한다

파일과 DB를 서로 다른 시점에 백업하면 복원 후 데이터가 맞지 않을 수 있습니다.

예를 들어 다음과 같은 상황입니다.

오전에 MariaDB를 백업합니다.
오후에 새 글과 이미지를 등록합니다.
저녁에 워드프레스 파일을 백업합니다.
두 백업을 한 세트처럼 복원합니다.

이 경우 uploads 폴더에는 새 이미지가 있지만 DB에는 해당 이미지 정보와 게시글이 없을 수 있습니다.

반대로 DB가 더 최신이고 파일 백업이 오래됐다면 게시글에는 이미지가 등록되어 있지만 실제 이미지 파일이 없어질 수 있습니다.

시점 불일치의 대표적인 증상

일부 게시글만 없음
최근 이미지가 표시되지 않음
플러그인 설정과 파일 버전이 맞지 않음
테마 설정은 있는데 테마 파일이 없음
최근 사용자 계정이 사라짐
플러그인 DB 업데이트가 반복됨
복원 후 일부 기능만 오류 발생

파일과 DB는 생성 날짜와 시간을 함께 기록해 하나의 백업 세트로 관리해야 합니다.

wordpress-files-2026-09-14.zip
wordpress-db-2026-09-14.sql.gz

3단계: 백업 파일의 크기와 내용을 확인한다

백업 파일이 존재해도 실제 내용이 비어 있거나 중간에 잘렸을 수 있습니다.

다음 항목을 확인합니다.

파일 크기가 0바이트가 아닌가
평소 백업 파일 크기와 크게 다르지 않은가
압축 파일이 정상적으로 열리는가
압축 해제 중 오류가 발생하지 않는가
DB 파일의 끝부분까지 데이터가 있는가
최근 백업만 비정상적으로 작은가
작업 중 NAS 저장공간이 부족하지 않았는가
백업 중 네트워크 연결이 끊기지 않았는가

사이트 규모가 비슷한데 평소 5GB였던 파일 백업이 갑자기 수MB로 생성됐다면 정상적인 전체 백업이라고 보기 어렵습니다.

DB 백업도 평소 수백 MB였는데 몇 KB만 생성됐다면 올바른 데이터베이스가 선택됐는지 확인해야 합니다.

4단계: Hyper Backup 형식을 일반 압축 파일처럼 다루지 않는다

Hyper Backup은 백업 방식에 따라 데이터를 자체 백업 형식으로 저장할 수 있습니다.

.hbk 형식은 일반 ZIP 파일처럼 압축을 풀어 사용하는 방식이 아닙니다. Hyper Backup, Hyper Backup Explorer 또는 호환되는 복원 환경에서 열어야 합니다.

Hyper Backup 복구가 안 될 때 확인할 항목

백업 작업이 연결되어 있는가
백업 대상 장치에 접속되는가
백업 저장소 경로가 바뀌지 않았는가
.hbk 내부 파일을 직접 수정하지 않았는가
백업 인덱스가 정상인가
무결성 검사가 완료됐는가
암호화 암호나 키 파일이 있는가
복원하려는 버전이 실제로 존재하는가
백업 대상 NAS의 저장장치 상태가 정상인가

백업 저장소 안의 파일이나 폴더를 File Station에서 직접 이동하거나 삭제하면 백업 구조가 손상될 수 있습니다.

일부 파일이 불필요해 보이더라도 백업 저장소 내부를 직접 정리해서는 안 됩니다.

5단계: 백업 무결성 검사 결과를 확인한다

Hyper Backup의 무결성 검사는 백업 데이터와 인덱스 구조를 확인하는 데 사용됩니다.

백업 파일이 보인다고 해서 모든 데이터 블록과 인덱스가 정상이라는 의미는 아닙니다.

무결성 검사에서 확인하는 영역

백업 데이터의 일관성
저장된 데이터 블록
백업 인덱스 구조
복원에 필요한 정보
원본과 백업 데이터 관계

무결성 검사 후 작업 상태가 ‘복원 전용’으로 바뀌었다면 백업 데이터 손상이 발견되었을 가능성이 있습니다.

이 경우 기존 백업 저장소에 계속 데이터를 추가하기보다 현재 복원할 수 있는 데이터를 먼저 확보하고 원본과 대상 저장장치의 상태를 확인해야 합니다.

무결성 검사만으로 충분하지 않은 이유

무결성 검사는 백업 구조와 데이터를 검사하지만 복원된 워드프레스가 정상적으로 실행되는지까지 확인하는 것은 아닙니다.

다음 문제는 별도 복구 테스트가 필요합니다.

올바른 DB가 포함됐는가
DB 사용자 정보가 맞는가
PHP 버전이 호환되는가
플러그인과 테마가 실행되는가
사이트 URL이 맞는가
이미지와 권한이 정상인가

6단계: 암호화 키와 비밀번호를 확인한다

암호화된 백업은 암호나 키 파일이 없으면 데이터가 정상적으로 존재해도 복원할 수 없습니다.

다음 정보를 확인합니다.

백업 암호
암호화 키 파일
키 파일을 저장한 위치
키 파일이 손상되지 않았는가
대소문자를 정확히 입력했는가
다른 백업 작업의 키와 혼동하지 않았는가

암호화 키를 백업 데이터와 같은 NAS에만 저장하면 NAS 장애 시 함께 잃을 수 있습니다.

백업을 만들 때 암호화 정보도 안전한 별도 위치에 보관해야 합니다.

암호나 키를 잃어버린 뒤 암호화를 우회해 복원하는 방법을 기대해서는 안 됩니다.

7단계: 복원할 NAS의 저장공간을 확인한다

복구 작업은 백업 파일 크기만큼의 여유 공간만 있으면 되는 것이 아닙니다.

압축 해제, 임시파일, 데이터베이스 가져오기와 캐시 생성 때문에 추가 공간이 필요할 수 있습니다.

저장공간 부족으로 나타날 수 있는 증상

압축 해제 중단
일부 파일만 복원됨
MariaDB 가져오기 실패
이미지 파일 누락
임시파일 생성 실패
복원 작업이 일정 지점에서 멈춤
사이트가 열리지만 DB 쓰기 실패
로그에 공간 부족 오류 표시

DSM 저장소 관리자에서 볼륨의 실제 사용 가능 용량을 확인합니다.

공유 폴더 휴지통, 스냅샷과 Synology Drive 버전이 공간을 차지하고 있다면 File Station에 보이는 파일 크기보다 실제 여유 공간이 적을 수 있습니다.

8단계: 워드프레스 파일을 올바른 문서 루트에 복원한다

파일을 정상적으로 복원했는데도 사이트가 열리지 않는다면 Web Station이 바라보는 문서 루트와 실제 파일 위치를 비교합니다.

워드프레스 루트 폴더에는 일반적으로 다음 항목이 바로 보여야 합니다.

wp-admin
wp-content
wp-includes
wp-config.php
index.php

압축 해제 과정에서 워드프레스 폴더가 한 단계 더 들어갈 수 있습니다.

web/wordpress/wordpress/wp-admin

Web Station의 문서 루트가 web/wordpress라면 실제 워드프레스 파일을 찾지 못할 수 있습니다.

확인할 항목

Web Station 문서 루트
실제 index.php 위치
압축 해제 폴더 구조
웹 포털과 연결된 웹 서비스
PHP 프로필
폴더 접근 권한

9단계: 파일 권한과 소유권을 확인한다

백업에서 파일을 복원하면 기존 NAS의 권한이 그대로 적용되지 않거나 새 NAS의 웹 서비스 계정과 맞지 않을 수 있습니다.

권한 문제로 나타날 수 있는 증상

403 Forbidden
이미지가 표시되지 않음
플러그인 활성화 실패
테마 CSS 파일 접근 실패
이미지 업로드 실패
캐시 폴더 생성 실패
wp-config.php 읽기 실패
업데이트 및 파일 수정 불가

시놀로지 Web Station에서는 웹 서비스가 파일에 접근할 수 있도록 관련 계정과 http 그룹 권한을 확인해야 할 수 있습니다.

모든 사용자에게 읽기·쓰기 권한을 부여하는 방식으로 해결해서는 안 됩니다. 워드프레스가 실제로 필요한 폴더와 작업 범위를 확인해 최소한의 권한을 설정해야 합니다.

10단계: 올바른 데이터베이스를 복원했는지 확인한다

NAS에서 여러 워드프레스 사이트나 애플리케이션을 운영했다면 백업한 DB가 어느 사이트의 것인지 혼동할 수 있습니다.

다음 항목을 확인합니다.

DB 백업 파일 이름
내보낸 날짜와 시간
DB 안의 사이트 주소
테이블 접두사
관리자 사용자
게시물 제목
사용 중인 플러그인 테이블

DB 파일 안에 테이블 생성문과 데이터 입력문이 존재하는지도 확인합니다.

다른 사이트의 DB를 가져오면 사이트가 열리더라도 전혀 다른 글과 사용자가 표시될 수 있습니다.

11단계: DB 가져오기가 완전히 끝났는지 확인한다

대용량 DB를 phpMyAdmin으로 가져올 때 업로드 크기, 실행 시간과 메모리 제한 때문에 작업이 중간에 멈출 수 있습니다.

화면에는 일부 테이블이 생성되어 복원이 된 것처럼 보일 수 있습니다.

불완전한 DB 가져오기의 증상

일부 테이블만 존재함
특정 플러그인에서 테이블 없음 오류 발생
게시글은 있지만 설정이 없음
DB 가져오기 중 시간 초과
SQL 구문 오류가 표시됨
가져온 DB 크기가 원본보다 지나치게 작음
사이트가 열리지만 관리자 기능이 오류를 냄

확인할 항목

가져오기 완료 메시지
오류가 발생한 SQL 위치
원본과 복원 DB의 테이블 수
원본과 복원 DB의 전체 크기
주요 테이블의 행 수
PHP 업로드 크기 제한
최대 실행 시간
MariaDB의 여유 공간

DB를 여러 부분으로 나눠 가져올 경우 실행 순서와 문자 집합도 확인해야 합니다.

12단계: wp-config.php의 DB 연결 정보를 확인한다

데이터베이스를 정상적으로 가져왔어도 wp-config.php가 다른 DB를 바라보면 기존 사이트가 표시되지 않습니다.

다음 값을 확인합니다.

define('DB_NAME', 'wordpress_db');
define('DB_USER', 'wordpress_user');
define('DB_PASSWORD', 'database_password');
define('DB_HOST', 'localhost');

새 설치 화면이 나타나는 경우

다음 테이블 접두사도 확인합니다.

$table_prefix = 'wp_';

실제 DB 테이블이 site_posts, site_options처럼 site_로 시작하는데 wp-config.php에는 wp_로 지정되어 있으면 워드프레스가 기존 데이터를 찾지 못할 수 있습니다.

이때 새 설치를 진행하면 빈 테이블이 추가되어 복구 과정이 더 복잡해질 수 있습니다.

13단계: DB 사용자 권한을 확인한다

DB 이름과 비밀번호가 맞더라도 사용자에게 해당 DB에 대한 권한이 없으면 워드프레스가 정상적으로 작동하지 않을 수 있습니다.

다음 작업에 필요한 권한이 있는지 확인합니다.

데이터 읽기
데이터 입력
데이터 수정
데이터 삭제
테이블 생성 및 변경

복구 후 사이트 첫 화면은 열리지만 글 저장, 플러그인 활성화 또는 DB 업데이트가 실패한다면 읽기만 가능하고 쓰기 권한이 부족한 상태일 수 있습니다.

관리 편의를 위해 DB 사용자에게 모든 데이터베이스의 전체 권한을 부여하기보다 해당 워드프레스 DB에 필요한 권한을 부여합니다.

14단계: PHP와 플러그인 버전 차이를 확인한다

백업 데이터가 정상이어도 복구 대상 NAS의 PHP 환경이 달라지면 사이트가 실행되지 않을 수 있습니다.

예를 들어 기존 NAS에서는 오래된 PHP 버전을 사용했지만 새 NAS에서는 더 높은 PHP 버전만 연결되어 있을 수 있습니다.

호환성 문제의 증상

치명적인 오류
흰 화면
500 오류
플러그인 활성화 실패
정의되지 않은 함수 오류
관리자 페이지 접속 불가
특정 기능만 작동하지 않음

확인할 항목

기존 NAS의 PHP 버전
새 NAS의 PHP 버전
Web Station에 연결된 PHP 프로필
활성 PHP 확장 모듈
워드프레스 버전
테마 버전
플러그인 버전
PHP 메모리 제한

복구 과정에서 워드프레스와 PHP, 플러그인을 동시에 최신 버전으로 올리면 어떤 변경이 오류를 만들었는지 알기 어렵습니다.

먼저 백업 당시와 최대한 비슷한 환경에서 복구한 뒤 정상 작동을 확인하고 단계적으로 업데이트하는 것이 좋습니다.

15단계: 사이트 URL과 복구 주소를 확인한다

기존 워드프레스 DB에는 백업 당시 사용하던 사이트 주소가 저장되어 있습니다.

새 NAS에서 내부 IP나 임시 도메인으로 복원하면 기존 도메인으로 자동 이동할 수 있습니다.

기본 테이블 접두사를 사용한다면 wp_options에서 다음 값을 확인합니다.

home
siteurl

URL 문제의 증상

새 NAS로 접속하면 기존 NAS로 이동
로그인 후 다시 로그인 화면 표시
관리자 페이지가 다른 주소로 이동
이미지가 이전 도메인에서 불러와짐
HTTP와 HTTPS 사이에서 무한 리디렉션
내부 IP 테스트가 불가능함

wp-config.php에 URL을 강제로 지정한 설정이 있는지도 확인합니다.

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

새 도메인으로 복구하면서 DB 안의 URL을 변경해야 한다면 단순 문자열 치환으로 모든 값을 수정하지 않는 것이 좋습니다. 플러그인과 테마 설정에 직렬화된 데이터가 포함되어 있으면 손상될 수 있기 때문입니다.

16단계: uploads 폴더와 DB 연결 상태를 확인한다

게시글은 정상적으로 보이지만 이미지가 나타나지 않는다면 DB 복원은 성공했지만 파일 복원이 불완전할 수 있습니다.

일반적인 미디어 파일 경로는 다음과 같습니다.

wp-content/uploads

이미지 복구 실패 원인

uploads 폴더가 백업에서 제외됨
최근 업로드 파일만 누락됨
잘못된 경로로 복원함
폴더 권한이 맞지 않음
DB에 이전 도메인 주소가 남음
원본은 있지만 자동 썸네일이 없음
대소문자가 다른 파일명
백업 파일과 DB 시점이 다름

본문에 저장된 이미지 주소와 실제 파일 경로를 비교하면 URL 문제인지 파일 누락인지 구분할 수 있습니다.

17단계: 플러그인 백업 파일의 복원 조건을 확인한다

워드프레스 백업 플러그인은 자체 압축 형식과 복구 절차를 사용할 수 있습니다.

백업 파일만 갖고 있어도 다음 조건이 맞지 않으면 가져오기가 실패할 수 있습니다.

복구용 플러그인 버전
무료·유료 버전의 용량 제한
PHP 업로드 제한
PHP 실행 시간
NAS 메모리
압축 해제 공간
파일 접근 권한
플러그인 자체 백업 형식
분할 백업 파일 전체 존재 여부

분할 백업은 여러 파일 중 하나만 없어도 전체 복구가 실패할 수 있습니다.

예를 들면 다음처럼 구성될 수 있습니다.

backup-part1
backup-part2
backup-part3
database
manifest

가장 큰 파일 하나만 사이트 전체 백업이라고 판단하지 말고 같은 작업에서 생성된 모든 파일이 있는지 확인해야 합니다.

18단계: 백업 안에 백업이 포함된 구조를 확인한다

워드프레스 백업 플러그인의 저장 폴더를 다시 전체 사이트 백업에 포함하면 이전 백업 파일이 새 백업 안에 들어갈 수 있습니다.

이 경우 파일 크기는 매우 커지지만 실제 복구 품질이 좋아지는 것은 아닙니다.

오히려 다음 문제가 생길 수 있습니다.

백업 생성 중 저장공간 부족
압축 파일 손상
복원 시간 증가
불필요한 파일까지 복원
백업 프로그램 시간 초과
무결성 검사 시간 증가

백업 대상에서 기존 백업 폴더와 캐시, 불필요한 로그를 제외할 수 있는지 확인합니다.

다만 제외하기 전에는 실제 운영 데이터가 아닌지 판단해야 합니다.

복구 실패 원인 판단표

확인 결과	가능성이 높은 원인	다음 조치
백업 파일 크기가 비정상적으로 작음	백업 중단 또는 대상 누락	작업 기록과 백업 범위 확인
새 설치 화면 표시	DB 연결·접두사 불일치	`wp-config.php`와 테이블 비교
DB 연결 오류	MariaDB·계정·비밀번호	DB 서비스와 접속 정보 확인
글은 있지만 이미지가 없음	uploads 누락·시점 불일치	파일 백업과 DB 날짜 비교
이미지는 있지만 최근 글이 없음	오래된 DB 백업	올바른 DB 버전 확인
흰 화면 또는 500 오류	PHP·플러그인·테마	백업 당시 실행 환경 비교
복원 중 시간 초과	DB·파일 크기, PHP 제한	로그와 제한값 확인
Hyper Backup을 열 수 없음	저장소·인덱스·키 문제	무결성 및 암호화 정보 확인
관리자 로그인이 반복됨	URL·쿠키·HTTPS	`home`, `siteurl`, 프록시 확인
게시물만 404	고유주소 규칙	재작성 설정 갱신
복원 후 일부 기능만 오류	플러그인 파일·테이블 불일치	플러그인과 DB 버전 확인
파일 쓰기와 업로드 실패	권한 문제	웹 서비스 계정 권한 확인

가장 효율적인 복구 진단 순서

현재 장애 상태의 파일과 DB를 별도로 보관합니다.
백업 생성 날짜와 복원하려는 시점을 확인합니다.
파일 백업과 DB 백업이 모두 있는지 확인합니다.
두 백업의 생성 시간이 일치하는지 비교합니다.
백업 파일 크기와 압축 상태를 확인합니다.
Hyper Backup이라면 무결성과 암호화 정보를 확인합니다.
복구 대상 NAS의 여유 공간을 확인합니다.
워드프레스 파일을 올바른 문서 루트에 복원합니다.
파일 권한과 Web Station 서비스를 확인합니다.
MariaDB에 올바른 DB를 가져옵니다.
원본과 복원 DB의 테이블 수와 크기를 비교합니다.
wp-config.php의 DB 정보와 테이블 접두사를 확인합니다.
PHP 버전과 확장 모듈을 백업 당시 환경과 비교합니다.
home과 siteurl을 확인합니다.
게시글, 이미지와 관리자 로그인을 각각 테스트합니다.
일부 기능만 실패하면 관련 플러그인을 확인합니다.
전체 복구가 끝난 뒤 외부 도메인과 HTTPS를 연결합니다.

복구할 때 피해야 할 조치

새 설치 화면에서 설치를 진행하지 않는다

기존 DB 연결이나 테이블 접두사가 잘못된 상태일 수 있습니다.

복구 실패 후 같은 위치에 반복해서 덮어쓰지 않는다

여러 버전의 파일이 섞이면 어떤 파일이 원본인지 구분하기 어려워집니다.

DB를 가져오기 전에 기존 DB를 바로 삭제하지 않는다

현재 DB에 백업 이후의 최신 글이나 설정이 남아 있을 수 있습니다.

Hyper Backup 저장소 내부를 직접 수정하지 않는다

파일 일부를 이동하거나 삭제하면 백업 인덱스와 데이터 구조가 손상될 수 있습니다.

PHP 버전을 무작정 반복 변경하지 않는다

오류가 달라질 수 있으며 다른 웹사이트에도 영향을 줄 수 있습니다.

암호화 키를 백업 파일과 같은 장소에만 보관하지 않는다

NAS나 저장장치 장애 시 백업과 키를 함께 잃을 수 있습니다.

운영 사이트에서 처음 복구 테스트를 하지 않는다

복구 과정의 실수로 정상 데이터를 덮어쓸 수 있습니다.

복구 가능한 백업을 만드는 운영 방법

파일과 DB를 한 세트로 관리한다

같은 시점에 생성한 파일과 DB 백업에 같은 날짜와 식별 이름을 사용합니다.

백업 완료 후 파일 크기를 확인한다

이전 백업과 비교해 갑자기 작아지거나 커진 경우 원인을 확인합니다.

정기적으로 무결성을 검사한다

Hyper Backup을 사용한다면 백업 데이터와 인덱스 구조가 정상인지 정기적으로 확인합니다.

별도의 환경에서 복구를 테스트한다

백업본으로 테스트 사이트를 구성해 관리자 로그인, 게시글, 이미지와 주요 기능이 정상인지 확인합니다.

복구에 필요한 정보를 함께 기록한다

다음 정보를 백업 자료와 별도로 안전하게 관리합니다.

워드프레스 버전
PHP 버전
MariaDB 버전
DB 이름과 사용자
테이블 접두사
문서 루트
도메인
백업 암호와 키
복구 순서

하나의 백업 위치에만 의존하지 않는다

같은 NAS의 다른 폴더에 있는 백업은 NAS나 볼륨 장애가 발생하면 원본과 함께 사용할 수 없게 될 수 있습니다.

백업 작업 성공 알림만 믿지 않는다

백업 파일 탐색, DB 내보내기 확인과 시험 복구까지 진행해야 실제 복구 가능성을 판단할 수 있습니다.

자주 묻는 질문

백업 파일이 정상적으로 있는데 왜 복구되지 않나요?

백업 대상 누락, 파일·DB 시점 불일치, 압축 손상, 잘못된 DB 정보, PHP 호환성과 권한 문제가 원인일 수 있습니다.

워드프레스 폴더만 백업해도 글을 복구할 수 있나요?

일반적으로 어렵습니다. 게시글과 페이지 내용은 MariaDB에 저장되므로 DB 백업이 필요합니다.

DB만 복원했는데 글은 보이고 이미지가 안 보이는 이유는 무엇인가요?

이미지 파일은 보통 wp-content/uploads에 저장됩니다. DB에는 이미지 정보가 있지만 실제 파일이 복원되지 않았을 수 있습니다.

Hyper Backup에서 성공으로 표시되면 안심해도 되나요?

성공 표시는 백업 작업 결과입니다. 무결성 검사와 실제 복구 테스트를 통해 필요한 데이터를 복원할 수 있는지 추가로 확인해야 합니다.

`.hbk` 파일을 압축 프로그램으로 열 수 있나요?

일반 압축 파일과 같은 방식으로 다루는 형식이 아닙니다. Hyper Backup 또는 호환되는 복원 도구를 사용해야 합니다.

암호화 암호를 잊어버려도 복구할 수 있나요?

암호화에 필요한 암호나 키 파일이 없으면 복구하기 어렵습니다. 암호화 정보를 별도 위치에 안전하게 보관해야 합니다.

복원 후 새 설치 화면이 나오면 데이터가 사라진 건가요?

DB 이름, 접속 계정이나 테이블 접두사가 잘못되어 기존 테이블을 찾지 못하는 경우가 많습니다. 새 설치를 진행하기 전에 DB 설정을 확인해야 합니다.

복원 후 500 오류가 나타나면 백업이 손상된 것인가요?

반드시 그렇지는 않습니다. PHP 버전, 확장 모듈, 플러그인 호환성과 파일 권한이 달라서 발생할 수 있습니다.

백업이 제대로 되는지 어떻게 확인할 수 있나요?

파일과 DB가 모두 있는지 확인하고, 백업 파일 크기와 무결성을 검사한 뒤 별도 환경에서 시험 복구를 진행하는 것이 가장 확실합니다.

마무리

시놀로지 NAS에 백업 파일이 있다고 해서 워드프레스 사이트를 반드시 복구할 수 있는 것은 아닙니다.

워드프레스는 파일과 MariaDB 데이터베이스가 함께 작동하고, 복원 환경의 PHP, Web Station, DB 계정, 파일 권한과 사이트 URL까지 맞아야 정상적으로 실행됩니다.

복구가 실패하면 먼저 파일과 DB가 모두 존재하는지, 생성 시점이 같은지, 백업이 완전한지 확인해야 합니다.

새 설치 화면이 나타나면 DB 정보와 테이블 접두사를 확인하고, 글은 있지만 이미지가 없으면 uploads 폴더와 백업 시점을 비교합니다. 흰 화면이나 500 오류가 나타난다면 PHP와 플러그인·테마 호환성을 점검해야 합니다.

Hyper Backup을 사용한다면 백업 저장소 내부를 직접 수정하지 말고 무결성 검사, 인덱스와 암호화 정보를 확인해야 합니다.

가장 중요한 것은 운영 사이트에 장애가 발생한 뒤 처음 복구를 시도하지 않는 것입니다.

백업을 만든 뒤 별도의 환경에서 파일과 DB를 실제로 복원해 보고 관리자 로그인, 게시글, 이미지와 핵심 기능까지 확인해야 합니다.

백업의 기준은 ‘파일이 있다’가 아니라 원하는 시점의 워드프레스 사이트를 다시 실행할 수 있다여야 합니다.

IT왕세자

백업 성공과 복구 성공은 다른 결과다

먼저 복구 실패 증상을 구분한다

워드프레스 복구에 필요한 백업은 두 가지다

워드프레스 파일에 저장되는 데이터

MariaDB 데이터베이스에 저장되는 데이터

1단계: 백업 안에 무엇이 들어 있는지 확인한다

DB 백업 파일의 대표적인 형태

2단계: 백업 파일과 DB의 시점이 같은지 확인한다

시점 불일치의 대표적인 증상

3단계: 백업 파일의 크기와 내용을 확인한다

4단계: Hyper Backup 형식을 일반 압축 파일처럼 다루지 않는다

Hyper Backup 복구가 안 될 때 확인할 항목

5단계: 백업 무결성 검사 결과를 확인한다

무결성 검사에서 확인하는 영역

무결성 검사만으로 충분하지 않은 이유

6단계: 암호화 키와 비밀번호를 확인한다

7단계: 복원할 NAS의 저장공간을 확인한다

저장공간 부족으로 나타날 수 있는 증상

8단계: 워드프레스 파일을 올바른 문서 루트에 복원한다

확인할 항목

9단계: 파일 권한과 소유권을 확인한다

권한 문제로 나타날 수 있는 증상

10단계: 올바른 데이터베이스를 복원했는지 확인한다

11단계: DB 가져오기가 완전히 끝났는지 확인한다

불완전한 DB 가져오기의 증상

확인할 항목

12단계: wp-config.php의 DB 연결 정보를 확인한다

새 설치 화면이 나타나는 경우

13단계: DB 사용자 권한을 확인한다

14단계: PHP와 플러그인 버전 차이를 확인한다

호환성 문제의 증상

확인할 항목

15단계: 사이트 URL과 복구 주소를 확인한다

URL 문제의 증상

16단계: uploads 폴더와 DB 연결 상태를 확인한다

이미지 복구 실패 원인

17단계: 플러그인 백업 파일의 복원 조건을 확인한다

18단계: 백업 안에 백업이 포함된 구조를 확인한다

복구 실패 원인 판단표

가장 효율적인 복구 진단 순서

복구할 때 피해야 할 조치

새 설치 화면에서 설치를 진행하지 않는다

복구 실패 후 같은 위치에 반복해서 덮어쓰지 않는다

DB를 가져오기 전에 기존 DB를 바로 삭제하지 않는다

Hyper Backup 저장소 내부를 직접 수정하지 않는다

PHP 버전을 무작정 반복 변경하지 않는다

암호화 키를 백업 파일과 같은 장소에만 보관하지 않는다

운영 사이트에서 처음 복구 테스트를 하지 않는다

복구 가능한 백업을 만드는 운영 방법

파일과 DB를 한 세트로 관리한다

백업 완료 후 파일 크기를 확인한다

정기적으로 무결성을 검사한다

별도의 환경에서 복구를 테스트한다

복구에 필요한 정보를 함께 기록한다

하나의 백업 위치에만 의존하지 않는다

백업 작업 성공 알림만 믿지 않는다

자주 묻는 질문

백업 파일이 정상적으로 있는데 왜 복구되지 않나요?

워드프레스 폴더만 백업해도 글을 복구할 수 있나요?

DB만 복원했는데 글은 보이고 이미지가 안 보이는 이유는 무엇인가요?

Hyper Backup에서 성공으로 표시되면 안심해도 되나요?

.hbk 파일을 압축 프로그램으로 열 수 있나요?

암호화 암호를 잊어버려도 복구할 수 있나요?

복원 후 새 설치 화면이 나오면 데이터가 사라진 건가요?

복원 후 500 오류가 나타나면 백업이 손상된 것인가요?

백업이 제대로 되는지 어떻게 확인할 수 있나요?

마무리

댓글 0

광고 차단 알림

`.hbk` 파일을 압축 프로그램으로 열 수 있나요?