WordPress 백업을 Storage Server에: WPvivid로 하는 방법

웹사이트와 같은 서버에 놓여 있는 백업은 백업이 아닙니다. 디스크가 지워지거나 접속 권한을 빼앗기거나 설치본이 암호화되면 백업도 함께 사라집니다. 분리된 스토리지에 둔 복사본만이 진짜 보험입니다.

이 가이드는 거기까지 가는 가장 빠른 길을 보여 드립니다. 무료 플러그인 하나로 WordPress를 SFTP를 거쳐 Storage Server에 백업하고, 일정과 보관 규칙까지 함께 거는 방법입니다. 설정은 15분이면 끝납니다.

WPvivid을 쓰는 이유

선택의 폭은 한 가지 점에서 놀랄 만큼 좁습니다. 중요한 것은 무료 버전에서 전송이 암호화되는지입니다.

평범한 FTP는 접속 정보와 내용을 암호화하지 않고 보냅니다. 사용자 테이블까지 들어 있는 데이터베이스 전체를 담은 백업에는 좋은 생각이 아닙니다. 그래서 WPvivid이 자연스러운 선택이 됩니다. 활성 설치 수가 900,000건을 넘고, 가장 최근 업데이트는 2026년 9월이었습니다.

1단계: 스토리지에 하위 계정 만들기

고객 포털의 Storage Server 아래에서 백업 전용 하위 계정을 하나 만들고, 시작 디렉터리를 /backup/wordpress로 두세요. 이것은 들리는 것보다 중요합니다. 접속 정보가 곧 WordPress 데이터베이스에 들어가게 되는데, 그것을 거기서 찾아낸 사람이 이 디렉터리 하나 말고는 아무것도 손에 넣지 못하게 해야 하기 때문입니다.

같은 단계에서 “접근 설정”의 스위치 두 개를 확인하세요.

• SSH / SFTP / SCP / rsync가 허용되어 있어야 합니다.
• 외부 접근 허용이 켜져 있어야 합니다. 그러지 않으면 웹 서버가 인터넷을 거쳐 스토리지에 닿지 못합니다.

새로 주문한 서버에서는 둘 다 켜져 있습니다. 호스트명과 사용자명을 적어 두세요. 이 글의 예시는 아래 값을 사용합니다.

2단계: 무엇을 설정하기 전에 먼저 연결을 확인하기

이렇게 해 두면 나중에 헤맬 일이 많이 줄어듭니다. 웹 서버에 셸 접근이 있다면 이렇게 확인합니다.

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "포트 23 연결 가능"

셸 접근이 없다면 웹 디렉터리에 pruefen.php 파일을 하나 올려 두고, 한 번 호출한 다음 다시 지우세요.

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? '포트 23 연결 가능' : '연결 실패: ' . $t;

연결이 전혀 이뤄지지 않는다면, 호스팅 업체가 이 포트로 나가는 연결을 막고 있는 것입니다. 공유 호스팅에서는 드물지 않은 일입니다. 그러면 업체에 문의하거나, 포트 443에서 돌아가는 WebDAV로 가는 길이 남습니다.

3단계: 플러그인 설치하고 대상 등록하기

WordPress 관리 화면의 플러그인, 새로 추가에서 WPvivid Backup & Migration을 검색해 설치하고 활성화하세요. 그러면 왼쪽에 WPvivid Backup 메뉴가 나타납니다.

거기서 Remote Storage 탭을 열고 SFTP를 고릅니다. 입력란은 이렇게 채웁니다.

Test and Add를 누르면 플러그인이 저장하기 전에 연결을 확인합니다. 그것이 실패한다면 열 번에 아홉 번은 포트가 틀렸거나 외부 접근 허용이 꺼져 있는 경우입니다.

4단계: 첫 백업은 손으로

Backup & Restore 탭에서 Database + Files (WordPress Files)를 고르고, 대상으로는 방금 만든 항목과 함께 Send backup to remote storage를 고릅니다. 그다음 Backup Now입니다.

첫 실행은 크기에 따라 몇 분이 걸립니다. 그동안 브라우저 창은 열어 두세요. 플러그인이 반복 호출로 진행을 밀고 나가기 때문입니다.

5단계: 일정과 보관

Schedule 탭에서 일정을 켭니다. 실무에서 잘 통하는 조합은 이렇습니다.

시각은 주요 방문자의 심야 시간대에 두세요. 보관 개수는 Settings에서 정하며, 거기에는 원격 스토리지의 오래된 백업도 함께 지울지 정하는 스위치도 있습니다. 그 스위치를 켜 두세요. 그러지 않으면 스토리지가 시간이 지나면서 가득 찹니다.

이때 기억해 둘 점이 있습니다. Storage Server의 스냅샷은 그와 별개로 돌아가는 추가 계층입니다. 요금제에 따라 수동 스냅샷을 10개, 20개, 30개 또는 40개 쓸 수 있고, 자동 스냅샷도 그와 같은 수만큼 있습니다.

6단계: 백업이 쓸 만한지 확인하기

이 단계가 가장 자주 건너뛰어지고, 가장 중요합니다. 스토리지에 실제로 무엇이 놓여 있는지 직접 보세요.

sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye

두 가지를 보세요. 파일 크기가 그럴듯해야 하고, 데이터베이스 아카이브와 파일 아카이브가 모두 있어야 합니다. 몇 킬로바이트짜리 아카이브는 성공이 아니라 실패입니다.

그리고 진짜 시험이 남았습니다. 백업을 테스트 설치본에 한 번 복원해 보세요. 한 번도 확인하지 않은 백업은 추측일 뿐입니다.

복원, 그리고 걸리는 한 가지

무료 버전에서는 원격 스토리지에 놓인 백업을 곧바로 되돌릴 수 없습니다. 원격 백업의 복원은 유료 버전에 들어 있기 때문입니다. 그래도 무료로 가는 길은 통하고, 몇 분만 더 걸릴 뿐입니다.

1. 아카이브를 SFTP로 스토리지에서 내려받습니다.
2. 플러그인의 Backup & Restore에서 Upload 영역을 열고 아카이브를 올립니다.
3. 올린 백업이 목록에 나타나고, 거기서 복원할 수 있습니다.

비상 계획을 세울 때 이 우회로를 함께 셈에 넣으세요. 진짜 사고가 났을 때 중간에 내려받기가 하나 더 있다는 사실을 처음 알게 되면, 잃지 않아도 될 시간을 잃습니다.

이 길이 끝나는 지점

모든 백업 플러그인은 PHP 안에서 돌아가므로 시간과 메모리 한계에 부딪힙니다. 전체 크기가 몇 기가바이트를 넘으면 느려지고, 미디어 라이브러리가 매우 크면 실행이 어느 순간 중단됩니다.

그때 더 나은 길은 rsync 또는 BorgBackup입니다. 둘 다 서버의 일정에서 바로 돌아가고, 둘 다 스토리지에서 기본으로 지원됩니다.

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub3@u123456.storage.kernelhost.net:/dateien/

이 방법은 바뀐 부분만 보내고 PHP 한계를 모릅니다. 다만 셸 접근이 있는 자체 서버가 필요합니다. 이 길에 관한 더 자세한 내용은 Storage Server를 내 웹사이트에 활용하기에 있습니다.

WordPress의 다른 부분, 곧 미디어 라이브러리와 다운로드를 스토리지로 옮길 수 있는지, 그리고 그 한계가 어디인지는 WordPress에서 Storage Server 활용하기에서 다룹니다.

가장 흔한 네 가지 실수

• 23이 아니라 포트 22. 플러그인은 22를 제시하지만, 우리 스토리지는 23에서 듣습니다.
• 외부 접근 허용이 꺼져 있음. 그러면 고객 포털에서 하는 확인은 되지만, 웹 서버에서 하는 확인은 안 됩니다.
• 하위 계정이 아니라 주 계정. 접속 정보가 그다음부터 웹사이트의 데이터베이스에 놓입니다. 주 계정이라면 거기에 모든 것이 걸립니다.
• 오래된 백업을 전혀 지우지 않음. 원격 스토리지에 대한 보관 규칙을 켜 두지 않으면 공간이 가득 차고, 어느 순간 백업이 조용히 실패합니다.

어떤 요금제가 맞는지

WordPress 사이트 하나의 백업이라면 1 TB에 9.99유로인 Storage-1으로 아주 오래 버팁니다. 가늠해 보자면, 전체 크기가 5 GB인 중간 규모 사이트는 백업 10개를 보관할 때 약 50 GB를 차지하므로 요금제의 5퍼센트입니다.

모든 Storage Server는 독일에 있고, 하위 계정을 최대 100개까지 허용하며, SFTP 외에 SMB와 WebDAV, rsync, BorgBackup도 지원하고 설치 비용이 없습니다. 정산은 선불 방식이고 최소 계약 기간이 없으므로, 작게 시작해서 사이트가 늘어날 때 함께 키우면 됩니다.