はじめに
さくらインターネットからエックスサーバーへの移行（蛮行）を開始して以来，幾多の困難を経験してきた。もちろん，ぼくだけの困難である。途中，挫けそうになったこともあった。移行開始日は3月11日である。その後，50日かけて，バックアップの復元に成功して，今日でほぼ，2ヶ月半。
ネット上の情報やサーバーのサポートなどは，全然と言って良いほど役に立ちませんでした。ブレークスルーをもたらしたのは，WPvividとPerplexityと言って良いと思います。
1. 膨張するデータベース
さくらインターネットからエックスサーバーに移行すべく進めてゆく過程で，データベースの内容を知る必要がでてきた。GitHubが提供するおそらく最高峰のエディターVisual Studio Codeを使って，UpdraftPlusで作成したバックアップファイルを解凍して，データベースを参照し，データベースの中身を見ることができた。テキストとスクリプトだけで構成されている。テキストエディターで見ているのであるから当然だ。そのファイルが3GBを超えているのである。
データベースだけでなくWordPressの全ファイルを使ってUpdraftPlusで，エックスサーバーに復元しようとするのであるが，ことごとく失敗した。そうこうするうちに，さくらインターネットから，毎日，データベース規定容量（3GB）オーバーの警告が毎日来るようになった。場合によっては，さくらの方で当方のWordPressサイトを停止するという。コンテンツの削除をするなど処置を取れと。
2. 無料版プラグインWPvivid
このアプリに偶然出会った。ぼくの検索活動では長く引っ掛からなかったものである。このアプリのすごいところは，無料版なのに，復元の際の制限がかかっていないところである。他のアプリには復元の際の容量制限がある。この視点で調べないとこの事実に辿り着けない。多くのWordPressはdatabaseも他のファイルもかなり軽い。特にネット上でこの種のテーマで発信している人々のサイトは軽い。だから，自分の限界からアプリを利用するからわからないのである。
デフォルトで無料版WPvividを使ってもぼくのようにdatabase 3GB超，他のファイルで25GB超のサイトを移行することはできない。Settingsでのパラメータ設定にその鍵があった。
3. データベースの痩身化
この課題についても苦戦した。いま，ここでは，ぼくのWordPressサイトが肥大化した理由をのべる。いま，Mariss Jansons指揮オスロ交響楽団演奏Jean Sibelius 作曲 交響曲第2番第3楽章を聴いながら，思いの出るまま書き綴っている。以前，投稿を作成していて，保存（Publish）をせずに放っておいて，その原稿を失い，頻繁に保存するようになり，それが常態化していた。
保存をするたびにその履歴が蓄積して，データベースが肥大化してゆくのだという（Perplexityさん曰く）。以前，ぼくは父関係の原稿をこのWordPressの固定ページに3ヶ月以上，緊張感をもって，書き連ねていた。公開していることで，このテーマに敵対する読者を想定し，ある問題について。その敵対する関係の方が来訪されたりもした。
ある段階で公開を避けて書き続けた方が良いと考えて，Microsoft Wordに切り替えて，Kindle版発行の作業を進めていた。その作業のいわばピークの時に，サーバー移行を始めたことで，この作品作成は休止中になっている。
のちにわかったのであるが，この原稿がどうもデータベースの肥大化に最も貢献したようである。何度も保存を繰り返してきたからである。時にはひと段落を作成するのに，何十回と保存したかもしれない。失いたくなかったからである。
実は記事作成中にその記事の保存ができなくなった失敗を回避する道を知った。エックスサーバーで，さくらのサイトをテーマから二分する過程で，記事の削除をしている時に，draftという分類があって，ここに失ったと思っていた記事があったのである。このドラフトは，編集してアップロードできるのである。失ったと思ったら，管理画面に入って，PostsかPagesのドラフトを見つければ良いのである。
では，今後，データベースの肥大化を防ぐことができるか。Microsoft Wordのアウトラインプロセッサーで書き込んで，画像なども溜め込んで，一応の完成をみてから，WordPressにコピペするのである。4月末から1ヶ月以上，この手法をとってきた。
ぼくはこのWordPressサイト（https://motochan.info/wp, 二分して新設httops://motochan.site/wp）に新規に追加記事を2025年5月26日，はじめて作成している。Microsoft Wordで書き溜めてきた記事を公開するのはできない可能性がある。気持ちが続かないのである。この記事はMicrosoft Wordではなくて，WordPressに直接書き込んでいる。ぼくの性格に起因するものである。
とにかく，大作をWordPressで書き連ねる手法は自ら首を絞めることになる。その一部を作成するための作業の断片をネット上に公開してゆく形がいいと思う。思考実験をWordPressの記事で示して，その結果も取り込んで大作をMicrosoft Wordのアウトラインプロセッサーで進めてゆくのが最上の流れであろう。
なお，挿入図（のサイズ）はデータベースには影響を与えない。サーバーに用意されている容量は500GBである。いま，バックアップファイルを積み上げている段階で，半分近くを使ってしまった。まあ，ある程度見えてきたら，バックアップファイルの適当な保存容量を決定したいと思っている。
4. WPvivid Proによるバックアップを通じて
無料WPvividではスケジュールバックアップの選択肢が限られている。この点を打開すべく，有料版を購入した。ライフタイムで$99だった。この種のプラグインとしてはかなり格安だ。サブスクリプションしかないし。
さくらインターネットで運用してきたWordPressのサイトをエックスサーバーの二つのドメインに移行または復元して，その後，テーマに応じてコンテンツを削除して，ほぼコンテンツが重ならない状態にした。そして，バックアップを始めたのである。
WPvivid Proは有料版ながら，ぼくが想像したものに比べて，かなり選択肢が限られていた。そのいくつかを次に。
1 バックアップ先の選択肢は，Localhostとremote storage，が用意されているはずであるが，増分バックアップの場合，そのいずれかを選択しなければならない。多様なスケジュールの設定をしたいので，この企業の売りとされる選択肢はぼくからすると魅力がなかった。
2 リモートストレージとしてGoogle Driveをレンタルしているが，100GBに過ぎないのでバックアップ回数は限定される。圧縮ファイルで一つのサイトが14GBほどで2サイトで30GB弱。最大3回分だ。他のコンテンツも少量ある。バックアップには一つのサイトで2時間半もかかる。
なぜ，リモートストレージなのか。Perplexityさんに聴いてみた。過去9年間サクラレンタルサーバを借りていて問題がなかったことを反論とした。
——— 引用〜
さくらインターネットは長年の実績があり、サーバーの稼働率も99.99%以上と非常に高く、24時間体制の監視やRAID10によるデータ保全、耐震構造や停電対策など、インフラ面での信頼性は非常に高いと評価されています。また、最新のセキュリティ対策も施されており、外部からの攻撃に対しても強固な防御がなされています。
しかし、それでも「サーバーのリスクがゼロになる」わけではありません。どのレンタルサーバーでも、稀にサーバーダウンや障害が発生するリスクは残っています。また、WordPressは世界的なシェアの高さから標的にされやすく、脆弱性を突いた攻撃や不正アクセス、サイト改ざん、マルウェア感染などのリスクは常に存在します。
特にWordPressの場合、システムやプラグインの脆弱性を狙った攻撃が日常的に行われており、アップデートやセキュリティ対策を怠ると、被害に遭う可能性があります[4]。また、万が一サーバー自体が大規模な障害やサイバー攻撃、災害などで利用不能になった場合、サーバー内だけにバックアップがあると復旧が困難になることも考えられます。
まとめると、さくらインターネットのサーバーは非常に安定しており、9年間問題がなかったことは信頼性の証ですが、サーバー障害やセキュリティリスクが完全になくなることはありません。
そのため、今後も「バックアップの多重化」や「セキュリティ対策の継続」が重要です。長く問題がなかったとしても、リスクはゼロではないという認識を持ち、備えておくことが推奨されます。
引用〜おわり ———
かなりの説得性があり，リモートストレージ Google Driveへの週単位のバックアップは継続することにした。
3 Localhostと言っても，home > motochan.info (motochan.site) > public_html > wp > wp-content > wpvividbackups，のフォルダーのことである。wp\ よりも上位の階層にバックアップフォルダをセットすれば，WordPressに問題があった際に，被害を回避できる筈であるが，残念ながら，そして，ぼくにとっては驚くべきことに，そういう自由度がWPvividにはないのである。
そして，次の問題を現在も抱えている。
4.1 疑問をWPvividのサポートにぶつけた May 24, 2025
Subject: Request for Assistance with WPvivid Pro Scheduled Backup Issue
Dear Support Team,
I am writing to seek urgent assistance with an issue related to WPvivid Pro’s scheduled backup functionality.
Overview:
I am encountering inconsistent behavior with scheduled backups across two similar WordPress sites using WPvivid Pro. While backups on one site (motochan.info) execute as expected, the other site (motochan.site) fails to trigger backups automatically at the scheduled time. Instead, backups only initiate manually after I review the settings post-deadline. I would appreciate guidance to resolve this discrepancy.
Detailed Issue Description:
- Environment
- Both WordPress sites are hosted on “Xserver of Japan” under separate domains: motochan.info and motochan.site.
- These sites originated from a single WordPress instance split into two using different themes. The migration was completed successfully using the free version of WPvivid.
- I recently upgraded to WPvivid Pro for both sites.
- Current Issue:
- motochan.info: Daily scheduled backups work flawlessly, and confirmation emails are delivered promptly.
- motochan.site: Backups do not run automatically, and no confirmation emails are received.
- Critical Observation: When I navigate to the backup job settings (Action > Edit the job) and adjust the exclusion settings (Advanced Settings > Exclude Files/Folders Inside /wp-content/ Folder > Folders), selecting
wpvividbackups/ and clicking “Exclude Files/Folders/File Types” manually triggers the backup. This occurs despite the scheduled backup being pre-configured identically to motochan.info.
- Troubleshooting Steps Taken:
- Verified identical plugin configurations (including WPvivid Pro settings) across both sites.
- Confirmed no conflicts from other plugins or server-side restrictions.
Request:
Please investigate the root cause of this inconsistency and provide steps to ensure scheduled backups function autonomously on motochan.site, as they do on motochan.info.
Thank you for your prompt attention to this matter.
Sincerely,
Motoharu Koba
May 24, 2025, 14:40
https://wpvivid.com/contact-us に質問。
4.2 WPviividから回答 May 25, 2025
Hello,
Thanks for contacting WPvivid.
In our experience, issue appears usually because the site gets no regular visitors.
Please note that WordPress cron works only when the site has visits.
If there is no regular traffic to the site, you can consider setting up a server cron to replace WP Cron.
All the best,
Tony Robins
WPvivid Team丨https://wpvivid.com丨contact@wpvivid.com
Earn 50% Commission with WPvivid Affiliate Program
CompressX – Free Localhost AVIF, WebP Converter
ものすごく短い。ぼくの状況に驚くことなく，そうだ，と言っている。
Please note that WordPress cron works only when the site has visits. If there is no regular traffic to the site, you can consider setting up a server cron to replace WP Cron.
4.3 方針の変更
ぼくは現在，WPvivid ProのScheduled Backupで，両サイトで，深夜毎日，Localhostにバックアップを取り，週１回Google Driveにバックアップを取る形をしてきた。WPvividではバックアップ対象のサイトにアクセスが少ないとバックアップをしないようだ。エックスサーバーのバックアップサポートだとアクセスとは関係なく毎日（毎5分）バックされるらしい。
で，新たなバックアップ方式を考えた。
1 日々のバックアップはエックスサーバーに任せる。この情報収集はまだしていないが，Perplexityさんの回答は次のようだ。
——— 引用〜
エックスサーバーのバックアップ機能は、サーバー上のWebデータやメールデータ、MySQLデータベースを1日1回自動でバックアップ専用サーバーに保存し、過去14日分を保持しています[1][5]。このバックアップデータは、サーバーパネルから申し込むことで提供され、ユーザー自身でダウンロード・復元作業を行えます。
大容量データへの対応について：
- サーバー領域のWeb・メールデータやMySQLデータベースのバックアップは、基本的にファイルサイズの制限は設けられていませんが、ファイル数が極端に多い場合や、データベースのテーブル数が1,000を超える場合、またはバックアップ処理に大きな負荷がかかる場合は、バックアップ対象から除外されることがあります。
- 実際に大量のファイルや大容量データベースでも、通常は問題なくバックアップ・復元が可能ですが、極端なケースでは自動バックアップが無効化されることもあるため、注意が必要です。
復元の確実性について：
- バックアップデータからの復元は、Webデータ・メールデータ・MySQLデータベースそれぞれに対して行えます。
- 復元手順は公式マニュアルや多くの解説サイトで案内されており、管理画面からの操作も分かりやすく、特別なトラブルがなければ問題なく復元できます。
- ただし、エックスサーバー自身も「システムによる自動バックアップの完全性を保証するものではない」と明記しており、万が一のためにユーザー自身でも別途バックアップを取ることが推奨されています。
まとめ
- エックスサーバーのバックアップ機能は大容量サイトにも基本的に対応し、復元も問題なく実行できます。
- ただし、ファイル数やデータベースの構成によっては例外的にバックアップ対象外となる場合があり、完全な保証はありません。
- 重要なサイトや大容量の場合は、エックスサーバーのバックアップと併用して、WPvividなどのプラグインや手動でのバックアップも推奨されます。
引用〜おわり ———
2 Google Driveへのバックアップ保存はWPvividのIncremental Backupで実行
Google Driveの容量は100GBにすぎず，前述のように最大で2サイトで３回分の保存が限界であったが，増分バックアップであれば，１０回分は保存が可能であろう。週１回ではなく，3日に１回でも可能であろう。
5. リダイレクトに対する誤解
redirectとは，《コ》リダイレクトする、出力先を変更する◆コンピューターで命令を実行した結果作られる情報の出力先を変更すること，である。これは過去の遺物と言える。httpサイトをGoogleのセキュリティ観の変更で，httpサイトはhttpsサイトへの変更を迫られた。ぼくのかつてのサイトもそうだった。
で，ネット利用者が閲覧してきたサイトはhttpであったが，サイト運営者は否応なく，https（Hypertext Transfer Protocol Secure）に変更する。その結果，閲覧者はhttpではhttpsに辿り着けない。そこで，httpにアクセスしても，httpsにリダイレクトされる形が必要となったのである。
エックスサーバーにも，「サイト転送設定」のメニューが用意されている。これを実行すると，アクセスがループして，リダイレクトが繰り返され，ブラウザーの方でハイリスクのサイトとして認識され，アクセスできなくなる。こういう事態に何回か陥った。とにかく，リダイレクトの設定をしてはならない。自らのサイトのバックアップもできなくなる。
つづく
現時点で思いつくままに，サイト転送に関わって，記述した。このページ作成中には，２回だったか3回だったか，昨日から今晩にかけて，保存（Publish）した。データベースへの負荷を減らすべく，保存回数を減らした。まだSlugは日本語タイトルのままで英語表現にして，Permalinkを編集しよう。
以上，2025年5月27日。
次につづく：
エックスサーバーでの二つのWordPressサイトのバックアップ案 a Backup plan for two WordPress sites on Xserver