워드프레스 updraftplus는 백업 및 복원 솔루션 가운데 세계적으로 많은 호평을 받은 플러그인임에는 분명하다. 홈페이지를 운영한다는 것은 오늘날 굉장히 쉬운일이지만, 개인정보부터 보안, 백업까지 신경써야할 부분이 많다. 그러나 워드프레스의 경우는 세계적으로 사용자가 많은 만큼 지속적으로 개발자들이 이러한 수고로움을 덜 수 있는 플러그인들을 개발하고 있는데 백업과 복원을 쉽게 처리해줄 수 있는 대표적 플로그인이 바로 updraftplus이다.
여하튼 최근 있었던 updraftplus의 복구 과정에 있었던 일을 공유하며, 혹시 필자와 비슷한 경험으로 고생할 수 있는 다른 사람들에게 조금이나마 도움이 되고자 한다.
먼저 updraftplus는 스케줄을 입력해 놓으면 세팅에 따라 별로의 공간에 DB와 웹사이트 파일 전부를 백업할 수 있다. 웹사이트 파일의 경우 압축을 해제하고 그대로 FTP 등으로 업로드하면 되기 때문에 어려운 부분은 아니다. 그러나 DB의 경우는 사실 쉬운 부분은 아니다. 물론 가벼운 사이트를 운영하는 경우 굳이 updraftplus라는 프로그램을 사용하지 않고 phpmyadmin을 이용해서 백업과 복원을 하면 간단하게 해결이 된다. 문제는 고용량의 DB로 운영되는 사이트의 경우에는 여러가지 문제가 발생된다.
1. DB 복구의 어려움
대용량의 DB로 운영이 되는 웹사이트의 경우에는 간단히 phpmyadmin을 통해서 백업과 복원을 하는 것이 어렵다. 특히 DB의 파일이 2Gb 이상이 되는 경우는 서버가 가지고 있는 기본 스펙이나 php.ini의 세팅값에 의해 복구가 어렵거나 된다하더라도 복구 중간에 서버가 멈추는 현상이 일어날 수 있다.
만약 당신이 터미널 명령어에 익숙한 사람이라면 대용량 DB라도 덤프 명령어를 통해서 업로드하고 복원할 수 있겠지만, 서버를 터미널로 연결하는 것부터 여러가지 복잡한 절차가 있기 때문에 일반 개인이 하기에는 조금 난이도가 있는 편이다.
그러나 이러한 모든 과정을 쉽게 처리해주는 것이 바로 updraftplus라는 플러그인이다. 대용량의 DB라도 복구되는 과정을 하나씩 보여주며 많은 량의 DB도 안정적으로 복원을 할 수 있다.
2. DB 복구 실패과정
필자의 경우 서버를 오랫동안 사용하다보니 하드부터 하드웨어까지 어느정도 데미지가 있었던 상황이었다. 퍼포먼스 측면에서 상당히 부진하고, 속도도 많이 떨어져 새로운 장비를 구입해서 웹사이트를 옮기는 작업을 하였다.
새로운 장비를 구매하고 웹사이트의 모든 파일을 새로운 서버로 옮겨준 후 워드프레스를 다시 설치하고, updraftplus 플러그인을 이용하여 DB을 복원 시도를 하였다. 그러나 updraftplus의 진행화면에서 복구가 어느정도 진행된 후 계속 실패하고 다시시도를 해도 실패를 거듭 반복하는 것이었다.
필자의 경우는 특별히 워드프레스 데이터베이스 테이블 가운데 높은 요량을 가지고 있는 wp_usermeta 또는 wp_postmeta를 복원을 완성하지 못하고 updraftplus 플러그인이 계속 오류나는 상황이 지속되었다.
3. updraftplus 복구 실패의 원인 분석
DB의 기초 상식이 많지 않았던 필자로서 구글을 통해서 대용량 DB 복구시 해결방법들을 찾아보았다. 그리고 몇가지 원인들을 예상해 보았는다. 아래가 DB 복구시 확인해보아야할 할 사항들이었다.
1) php.ini 의 세팅값 - 일반적으로 '처리시간'과 관련된 수치를 높여주라는 것(예, max_execution_time)
2) 워드프레스 파일 권한인 제한되어 있어서 실패라는 것(권한의 제한이 있어서 FTP 등으로 권한을 777로 변경)
3) DB 백업시 생길 수 있는 오류로 인한 파일 손상
4) 서버 자체의 처리 스팩
위의 것들이 대체적으로 언급되는 솔루션들이었다. 그럼에도 불구하고 모든 것을 해보았지만, 약 3Gb가 넘는 필자의 데이터베이스는 복구되지 않았다.
4. 문제점 발견
필자는 원인을 분석하면서 데이터백업시 서버의 CPU 사용량을 체크해 보았다.
위의 그래프는 updraftplus로 복원시 실패했을 때의 CPU 그래프이다. 위의 경우는 안정적으로 그래프가 유지되다가 특정 구간에서 요동치는 모습이 보인다. 그 후 다시 안정을 찾았지만, 복원은 실패했다.
위의 그래프도 복원실패시의 그래프이다. DB를 복원하는데 CPU가 비정상적으로 움직이는 것을 볼 수 있다. 그래서 CPU 사용 중 어떠한 부분이 문제인지 확인해본 결과 sql 덤프 사용량이 갑자기 많아지는 현상을 확인할 수 있었따.
여기서 추론해볼 수 있는 것은 php.ini 세팅을 너무 높게 잡아서 sql 덤프의 문제가 생겼을 수도 있고, 아니면 새로 구입한 장비의 문제, 복원시 외부로부터 접속요청이 잦아 이것을 병행처리하지 못하는 문제 등등이 있었다.
5. 문제 해결
필자는 처음부터 복원을 다시 시도하고자 하였고 아래의 순서대로 진행하였다.
- 서버 초기화, 하드 모두 초기화 한 후 스토리풀 구성, 워드프레스 테마와 플러그인를 업로드 (복원 전동일한 updraft 버전)
- php.ini, 워드프레스 권한 모두 설정하지 않음. 초기세팅 그대로 진행
- 복구중 세션이 만료되었다며 로그인 창이 뜰 때 로그인 하지 않고, 그냥 X 눌러 닫기
- 진행하는 동안 updraftplus의 상단창에 last activity 가 계속 0으로 기록(대기하지 않고 계속 진행중이라는 뜻)
- 약 2시간 동안 DB 복원 성공
서버를 완전히 다 초기화하고, 하드도 포멧하여 다시 설치 후 updraftplus로 복원시 보이는 CPU 그래프이다. 데이터베이스 복원시 안정적으로 CPU가 작동하고 있었다는 것을 뜻한다.
여기서 알 수 있는 것은 서버의 상태에 따라 updraftplus의 복원이 좌우될 수 있다는 것이다. 서버의 상태는 다양한 요소에 의해 좌우될 수 있다. 만약 워드프레스의 파일을 옮겨주고, 복원하는 과정에서 특정 플러그인이 작동되어 sql 오류가 날 수도 있고, 서버에 설치되어 있는 앱들로 인하여 오류가 발생할 수도 있다. 또는 불필요하게 php.ini 세팅이나 워드프레스 사용권한 이런 것을 설정하면서 오류가 날 수 있다.
그러나 updraftplus는 php.ini 설정해줄 필요도 없고, 권한이나 별도의 앱도 필요 없다. 결국 핵심은 서버와 하드의 클린상태이고, 깨끗한 상태에서 백업 시도시 성공확률이 높다.
댓글