어제는 조금 특이한 작업을 받았습니다. 몇 년 전에 카페24에서 백업한 워드프레스 사이트의 데이터와 DB를 사용하여 사이트를 복구하는 작업이었습니다. 데이터와 DB에 이상이 없다면 정상적으로 복구되어야 하지만, DB 오류 때문에 복구가 되지 않았습니다. 카페24의 데이터베이스 복원 기능을 사용하니 일부만 복원되어서 phpMyAdmin을 통해 시도하니 "#1064 - 'SQL 구문에 오류가 있습니다.' 에러 같습니다" 오류를 비롯하여 여러 가지 오류가 발생하면서 임포트에 실패했습니다.

DB 임포트 시 "#1064 - 'SQL 구문에 오류가 있습니다.' 에러 같습니다." 오류가 발생하는 경우
카페24에서 백업한 데이터와 DB를 사용하여 사이트를 복원하는 작업을 진행했습니다.

그림과 같이 1개의 데이터 파일과 2개의 DB 파일을 제공받았습니다. 데이터 파일은 2024년 1월에, DB 파일은 2024년 1월과 2021년 10월에 각각 백업한 것 같습니다.
먼저 카페24에서 PHP 버전을 8.0으로 설정한 상태에서 복원을 시도해 보았습니다. 데이터는 SSH에 접속해서 압축을 해제했고, DB는 카페24의 DB 복원 기능을 사용해서 복원을 시도했습니다. DB 복구를 요청하면 3분 후에 확인하라는 팝업이 뜨지만, 계속 로드 중 화면이 계속 표시되었습니다.
오래 기다린 후에 (여전히 로드 중 화면이 표시되고 있는 상황에서) 사이트에 접속하니 치명적인 오류가 발생하여 치명적인 오류를 해결해 보려고 시도했지만, 너무 많은 치명적인 오류가 발생하여 PHP 7.4 환경에서 다시 시도하기로 했습니다. 그리고 동시에 클라우드웨이즈(Cloudways)에 워드프레스를 설치하고 DB 임포트를 시도해 보았습니다. 하지만 "Request Entity Too Large" 오류가 발생하면서 DB가 임포트되지 않았습니다.😥 아마 카페24에서 DB 임포트를 요청했을 때 이와 비슷한 오류가 발생하여 계속 로드 중 화면이 표시된 것이 아닌가 생각됩니다.
PHP 7.4에서 2024년도 DB를 임포트하려고 시도하니 아래와 같은 오류가 발생했습니다.
변수명이 필요합니다. (near "{" at position 77488)
변수명이 필요합니다. (near "\" at position 77493)
닫는 따옴표 " 가 팔요합니다. (near "" at position 77502)
SQL 질의: 복사
#1064 - 'SQL 구문에 오류가 있습니다.' 에러 같읍니다. ('akismet_history','a:3:{s:4:\"time\"' 명령어 라인 1)
phpMyAdmin에서 SQL 파일을 임포트할 때 발생하는 #1064 에러는 전형적인 문법 오류(Syntax Error)입니다. MySQL 엔진이 전달받은 쿼리를 읽다가 "무슨 뜻인지 이해할 수 없는 지점"에서 멈췄을 때 발생합니다.
#1064 에러는 일반적으로 다음과 같은 원인에 의해 발생한다고 합니다.
- MySQL / MariaDB 버전 간 문법 차이
- 파일 인코딩 문제 (UTF-8 BOM, 깨진 문자 등)
- SQL 파일이 손상되었거나 불완전하게 export됨
- 특수문자(\, ", ')가 올바르게 이스케이프되지 않음
- PHP 직렬화(serialized) 데이터 내 따옴표 충돌
- SQL 파일을 텍스트 편집기로 열었다가 저장하면서 변형됨
상기 그림에서는 백슬래시 이스케이프 처리 방식이 잘못되어 발생하는 문제입니다. 해당 부분을 찾아보니 아래와 같이 "INSERT INTO `wp_commentmeta` VALUES (2,132,'akismet_history','a:3:{s:4:\"time\";d:1518905635.653374;s:5:\"event\"; .." 라인이 문제가 되는 것 같았습니다.

오류 메시지의 핵심은 'akismet_history','a:3:{s:4:\"time\"' 부분입니다. 이것은 PHP 직렬화(serialized) 데이터인데, 원래 SQL에서는 다음과 같이 저장되어야 한다고 합니다.
'a:3:{s:4:\"time\";...'
-- 또는
'a:3:{s:4:"time";...'
Export 당시 \" 로 이스케이프된 문자열이, 다른 버전의 MySQL/MariaDB나 phpMyAdmin에서 임포트될 때 \" 를 올바른 이스케이프 시퀀스로 인식하지 못하고 구문 오류로 처리한 것입니다.
워드프레스 스팸 댓글을 처리하는 Akismet 플러그인은 메타 데이터를 PHP serialize 형식으로 DB에 저장하는데, 이 직렬화 문자열 안에 큰따옴표(")가 포함되어 있어 SQL import 시 특히 이 문제가 자주 발생한다고 합니다.
이 경우 SQL 파일에서 \"를 "로 치환한 후에 다시 임포트를 시도해 볼 수 있습니다.
또 다른 방법으로 INSERT INTO `wp_commentmeta`...로 시작하는 라인을 모두 주석 처리하는 것도 생각해 볼 수 있습니다.

또한, INSERT INTO `wp_comments` VALUES...로 시작하는 라인들도 주석으로 처리할 수 있습니다.

위와 같이 처리하면 댓글 데이터가 임포트가 안 되게 됩니다. 댓글이 중요하지 않을 때 이 방법을 이용할 수 있습니다.
이렇게 파일을 수정하여 다시 임포트를 시도하니 이 부분은 해결되었지만 또 다른 오류가 발생했습니다. 특히 포스트 안에 다음과 같은 악성 스크립트가 포함되어 있어 Export 엔진의 버그를 유발했거나 이스케이프 처리를 방해했을 가능성이 있는 것 같습니다.
<script>$NqM=function(n){if (typeof ($NqM.list[n]) == "string") return $NqM.list[n].split("").reverse().join("")...
단순히 이스케이프 처리 문제의 경우 sql 파일을 수정하여 수정이 가능했지만, 다음과 같은 문제가 발생하여 체크해 보니 엑스포트 과정에서 데이터가 손상되어 수정이 불가능한 상태였습니다.
분석 중에 1개의 오류가 발생했습니다.
값 23 이 예상되었지만, 22 가 발견되었습니다. (near "(" at position 118809)
INSERT INTO `wp_posts` VALUES (1871,2,'2017-08-30 00:59:09','2017-08-29 15:59:09','<span style="font-size: 12pt;"><strong><span style="color: #000080;"><img class="size-full wp-image-1765 alignleft" ...
위의 오류 메시지를 통해 알 수 있는 것은...
- wp_posts 테이블은 데이터를 넣어야 할 칸(Column)이 총 23개입니다.
- 그런데 현재 처리 중인 INSERT 문에는 데이터가 22개만 들어있습니다.
- 즉, 마지막 데이터가 기록되다가 중간에 툭 끊겨버린 것입니다.
마지막 데이터가 기록되다가 중간에 끊긴 이유로는 다음과 같은 것을 의심해 볼 수 있습니다.
- 서버 타임아웃/메모리 부족: DB 서버에서 SQL 파일을 만들다가 너무 긴 텍스트(본문 내용)를 처리하는 도중 과부하로 프로세스가 강제 종료되었습니다.
- 파일 전송/다운로드 오류: FTP나 웹 브라우저를 통해 SQL 파일을 다운로드하는 과정에서 네트워크 문제로 파일 끝부분이 잘렸습니다.
- 악성 코드/스크립트 간섭: 본문 내용 중에 포함된 <script> 태그들을 보면, 일반적인 데이터가 아니라 악성 스크립트(Malware)가 삽입된 것으로 보입니다. 이런 비정상적인 코드가 Export 엔진의 버그를 유발했거나 이스케이프 처리를 방해했을 가능성이 큽니다.
아마 Export 과정에서 타임아웃 등의 이유로 정상적으로 엑스포트가 완료되지 않아서 손상된 DB를 가지고 복구를 시도하니 복구가 될 리가 없었습니다. 그나마 다행인 것은 2021년도 DB 데이터가 있어서 그것으로 복원을 시도하니 문제없이 복원되었습니다.
카페24에서 DB를 백업해야 하는 경우 카페24의 DB 백업 기능에만 전적으로 의지하지 말고 다른 방법(예: phpMyAdmin에서 Export하거나 UpdraftPlus와 같은 워드프레스 백업 플러그인을 사용)으로 이중으로 백업하면 조금 안심할 수 있을 것입니다.
👉 워드프레스나 웹호스팅 관련 문제로 해결에 어려움을 겪는 경우 여기에서 서비스(유료)를 의뢰하실 수 있습니다.
참고
https://avada.tistory.com/3929
카페24 뉴매니지드 워드프레스 호스팅에서 지원하는 PHP 버전 (2026년 기준)
클라이언트의 워드프레스 사이트가 사라지고 도메인도 만료되었지만, 내용을 열람할 수 있도록 사이트를 복구하는 작업을 의뢰받았습니다. 사이트를 복원하기 위해서는 백업 데이터와 DB가 있
avada.tistory.com
https://avada.tistory.com/3916
클라우드웨이즈 최대 업로드 파일 크기가 2MB 또는 50MB로 표시되는 경우 해결 방법
클라우드웨이즈(Cloudways) 기반의 워드프레스 사이트에서 최대 파일 업로드 크기가 늘어나지 않아 고민이신가요? 서버 설정에서 업로드 한도를 100MB 이상으로 높였음에도 계속 2MB로 표기되거나 50
avada.tistory.com