WordPress のバックアップを Storage Server へ:WPvivid を使った手順
同じサーバーの上にあるバックアップは、バックアップではありません。本記事では、無料のプラグインで WordPress を SFTP で別の Storage Server にバックアップする方法を、15 分で終わる手順として解説します。
ウェブサイトと同じサーバーの上にあるバックアップは、バックアップではありません。ディスクを消されたり、アクセス権を奪われたり、インストール全体を暗号化されたりすれば、バックアップも一緒に失われます。別のストレージ上のコピーがあって、はじめて本当の備えになります。
本記事では、そこへ至る最短の道を示します。WordPress を SFTP で Storage Server にバックアップする無料のプラグインを使い、スケジュールと保持ルールまで設定します。作業は 15 分で終わります。
WPvivid を選ぶ理由
選択肢は、ある一点だけ意外なほど少なくなります。肝心なのは、無料版で暗号化された転送ができることです。
| プラグイン | 無料版でできること | 使えるか |
|---|---|---|
| WPvivid Backup & Migration | FTP と SFTP | はい |
| UpdraftPlus | FTP のみ、SFTP と WebDAV は有料 | 購入すれば可 |
| BackWPup | FTP のみ | 購入すれば可 |
通常の FTP は、認証情報も中身も暗号化せずに送ります。ユーザーテーブルを含むデータベース全体が入ったバックアップにとって、それは良い考えではありません。したがって WPvivid が自然な選択になります。有効なインストール数は 90 万件を超え、直近の更新は 2026 年 9 月です。
ステップ 1:ストレージにサブアカウントを作成する
カスタマーエリアの Storage Server のページで、バックアップ専用のサブアカウントを作成し、ホームディレクトリに /backup/wordpress を指定します。これは見た目以上に重要です。認証情報はこのあとすぐ WordPress のデータベースに保存されるので、それを見つけた人がこのディレクトリ 1 つ以外には何も到達できないようにしておくべきです。
同じ作業のついでに、「アクセス設定」で 2 つのスイッチを確認します。
- SSH / SFTP / SCP / rsync が許可されている必要があります。
- 外部からの到達可能性がオンになっている必要があります。オフだと、お使いのウェブサーバーからインターネット経由でストレージに届きません。
新しく注文したサーバーでは、どちらも最初から有効です。ホスト名とユーザー名を控えておいてください。本記事の例では次の値を使います。
| 項目 | 値の例 |
|---|---|
| ホスト名 | u123456.storage.kernelhost.net |
| サブアカウント | u123456-sub3 |
| ディレクトリ | /backup/wordpress |
| ポート | 23 |
ステップ 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 を選びます。各項目は次のように入力します。
| 項目 | 値 |
|---|---|
| Storage Alias | 自由に決めた名前、たとえば KernelHost Storage |
| Host | u123456.storage.kernelhost.net |
| Port | 23、提案される 22 ではありません |
| Username | u123456-sub3 |
| Password | サブアカウントのパスワード |
| Path | /、サブアカウントは最初から正しいディレクトリで始まるためです |
Test and Add を押すと、プラグインは保存する前に接続を確認します。これが失敗する場合、10 回のうち 9 回はポートが間違っているか、外部からの到達可能性がオフになっています。
ステップ 4:最初のバックアップを手動で
Backup & Restore タブで Database + Files (WordPress Files) を選び、保存先として、いま登録した項目を指定した Send backup to remote storage を選びます。そのあと Backup Now です。
最初の実行は、サイトの大きさによって数分かかります。その間はブラウザーのウィンドウを開いたままにしてください。プラグインは、繰り返しの呼び出しで処理を進めます。
ステップ 5:スケジュールと保持数
Schedule タブで、スケジュールを有効にします。実績のある設定は次のとおりです。
| 対象 | 周期 | 保持数 |
|---|---|---|
| データベース | 毎日 | 10 個 |
| データベースとファイル | 毎週 | 4 個 |
時刻は、主な訪問者にとって深夜にあたる時間に設定してください。保持数は Settings で設定します。同じ場所に、リモートのストレージ上の古いバックアップもあわせて削除するかどうかのスイッチがあります。これはオンにしてください。オフのままだと、ストレージはいずれ満杯になります。
なお、Storage Server のスナップショットは追加の層であり、これとは独立して動きます。プランに応じて、手動のスナップショットが 10 個、20 個、30 個、40 個使え、同じ数だけ自動のスナップショットも使えます。
ステップ 6:バックアップが使えるものかを確かめる
この手順は最も飛ばされがちで、しかも最も重要です。実際にストレージに何が置かれているかを見てください。
sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye
見るべき点は 2 つです。ファイルサイズが妥当であること、そしてデータベースのアーカイブとファイルのアーカイブの両方がそろっていることです。数キロバイトのアーカイブは、成功ではなく失敗です。
そしていよいよ本番の検証です。バックアップを一度、テスト環境に復元してみてください。検証していないバックアップは、ただの推測です。
復元の手順と、その落とし穴
無料版では、リモートのストレージ上にあるバックアップを直接戻すことはできません。リモートにあるバックアップからの復元は、有料版の機能です。それでも無料の方法で問題なく復元でき、かかる時間は数分増えるだけです。
- アーカイブを SFTP でストレージからダウンロードします。
- プラグインの Backup & Restore で Upload の領域を開き、アーカイブをアップロードします。
- アップロードしたバックアップが一覧に現れ、そこから復元できます。
この回り道は、緊急時の計画に織り込んでおいてください。万一のときに、まだダウンロードが 1 つ挟まることを初めて知る人は、無駄に時間を失います。
この方法の限界
バックアップのプラグインはどれも PHP の中で動くため、実行時間とメモリの上限にぶつかります。全体のサイズが数ギガバイトを超えると重くなり、メディアライブラリが非常に大きいと、いずれ処理が途中で止まります。
その場合に適しているのが rsync または BorgBackup です。どちらもサーバー上のスケジュールから直接動かせて、どちらも Storage Server がそのまま対応しています。
rsync -az --delete -e "ssh -p 23" \
/var/www/example.com/ \
u123456-sub3@u123456.storage.kernelhost.net:/dateien/
これなら変更分だけを転送し、PHP の上限とも無縁です。ただし、シェルを使える自前のサーバーが必要になります。この方法の詳細は Storage Server を自分のウェブサイトで使うで解説しています。
WordPress のほかの部分、つまりメディアライブラリやダウンロードをストレージに移せるか、そしてそこでの限界がどこにあるかは、Storage Server を WordPress で使うで解説しています。
よくある 4 つの失敗
- ポートを 23 ではなく 22 にする。プラグインは 22 を提案しますが、当社のストレージが待ち受けるのは 23 です。
- 外部からの到達可能性がオフになっている。この場合、カスタマーエリアからのテストは通るのに、ウェブサーバーからは通りません。
- サブアカウントではなくメインアカウントを使う。認証情報は、このあとウェブサイトのデータベースに残ります。メインアカウントだと、そこにすべてがぶら下がります。
- 古いバックアップが一度も削除されない。リモートのストレージ向けの保持ルールをオンにしていないと容量が満杯になり、いずれバックアップが何も言わずに失敗します。
どのプランが合うか
1 つの WordPress サイトのバックアップなら、1 TB の Storage-1 が月額 9.99 ユーロでかなり長く足ります。目安として、全体で 5 GB の中規模のサイトでバックアップを 10 個保持すると、使うのは約 50 GB、つまりプランの 5 パーセントです。
| プラン | 容量 | スナップショット | 料金 |
|---|---|---|---|
| Storage-1 | 1 TB | 手動 10 個と自動 10 個 | 9.99 EUR |
| Storage-2 | 5 TB | 手動 20 個と自動 20 個 | 29.99 EUR |
| Storage-3 | 10 TB | 手動 30 個と自動 30 個 | 39.99 EUR |
| Storage-4 | 20 TB | 手動 40 個と自動 40 個 | 69.99 EUR |
すべての Storage Server はドイツに設置されており、サブアカウントを 100 個まで作成でき、SFTP に加えて SMB、WebDAV、rsync、BorgBackup にも対応し、初期費用はかかりません。請求はプリペイド方式で最低契約期間もないため、小さく始めて、サイトが増えたときに大きくできます。
よくあるご質問
なぜ UpdraftPlus ではなく WPvivid なのですか?
ポートには何を入力すればよいですか?
専用のサブアカウントは必要ですか?
どのくらいの頻度でバックアップすべきですか?
バックアップはいくつ保持すべきですか?
ストレージから直接復元できますか?
とても大きなウェブサイトではどうすればよいですか?
バックアップが本当に使えるものかは、どう確かめますか?
バックアップでウェブサイトは遅くなりますか?
ストレージの料金はいくらですか?
2026 KernelHost GmbH。無断複写・転載を禁じます。本ガイドは著作権により保護されております。他のウェブサイトへの掲載は、一部のみの場合や編集を加えた場合であっても、当社の書面による同意なしには認められません。出典の明記とリンクを添えた引用は歓迎いたします。

