バックアップとリストア作業の備忘録

以下作業中なにしたか思い出しながらの覚書、備忘録ヨシ。多分手順通りではないし忘れてる作業あるから後日修正や加筆する、でもあてにしないで逐一調べてやって。

何が厄介ってサイトのバックアップと復元、バックアップは復元するまでキチンとバックアップ出来てるかわからない、BackWPup使ってたけど確認不足でマルチサイトの復元は無理でシングルサイトでも復元には要課金、…騙したなって思うやん?

慌ててUpdraftplusを入れてバックアップしてみるもマルチサイトは成功しにくい、しかも今回はサバ移行なので復元が有料オプション、やはり世の中金ですかね。BackWPupで700MB以下なら復元できるってなってたけど何故かウチのデータ700MB超えてんすよ、無理やん。

そもそも企業勢でもあるまいし個人でマルチサイト化なんてデメリットデカ過ぎ。マルチサイトのまま移行はできないと判断しシングルサイト化して完全手動復元とする、たまたまブログ以外はページも少なきゃデータも少ないので右クリック保存で対処する。

ひとまず旧WordPressでテーマ、プラグイン、WordPress本体を現PHPで出来るところまで更新。テーマ(themes)、プラグイン(plugins)、画像(uploads)をFTPでダウンロード。

マルチサイト化してる場合、uploadsのツリー最下部にsitesがあって子サイト分の番号フォルダが並び、各子サイト画像がそこに格納されてる、画像データに関してはシングルサイトに復元する際にどのフォルダからuploadsにするかを後から選んだらいいからuploadsフォルダごとダウンロードする。

マルチサイトやとデータベースがほんとに厄介、下記地獄の様子。

phpMyAdmin手動でデータベースダンプさせても復元したらエラーゲロ吐き、原因はまずプラグインを全解除してなかった点、プラグイン全解除で挑むとまたしてもエラー、今度はダンプSQLファイルをnanoで読み進めてWordpress Ping Optimizerがなんか悪さしてるのが発覚、コイツphpエラー原因やったりping連発したりいつもなんか悪さしてるな…

停止してもバックアップに不具合を生むWordpress Ping Optimizerは完全削除の必要がある、ブラウザ内の操作でWordpressから削除してもデータベースのテーブルにゴミを残す、キチンとバックアップするために必ずそっちも削除を。Wordpress Ping Optimizer停止、全摘出を強烈に鬼推奨する、WPO〇ね、ping送るくらいで調子乗んな〇ケが。

phpMyAdminのツリーから以下を見つけだして駆逐!

wp_cbnetpo_ping_optimizer

下記wp_optionテーブルも削除を

cbnetpo_last_ping_time

cbnetpo_options

cbnetpo_ping_num

cbnetpo_ping_optimizer

レンタルサバではひたすらphpMyAdminでの作業になる、滅多に触らんから全然慣れん。慣れてないから使い方消し方逐一検索して作業するしかない、ノリでやると取り返しつかんくなりがちやから要注意。クエリがどうたら本当に実行しますかと聞かれるとビビるし実行した後の返答が返り値が空でした(行数0)とか言われてコイツ会話成り立たんなと思うよね。しかしプラグインのゴミ残り過ぎ、マジでプラグイン嫌いになる。

プラグインのゴミを取り除いてダンプしたSQLファイルを確認、create databaseとかが無かったため、phpMyAdminで再度詳細なオプションで追加してダンプし直し、DBをnano直でテーブル名置換。マルチサイト化してる場合は_旧DB名_2_ってなってるのを単純な_に置換と、_旧DB名_を_に置き換え、この辺は鬼ググった、参考サイト4つくらい同時に見てたな。

そういや移行復元先のWordPress、PHP、MySQLのバージョンを揃えとかないといけない、がMySQLのバージョンだけメジャー一緒でマイナーも近かったからまんま行ったらいけた。

忘れがちな権限あたりもやる。

MySQLでGRANT ALL PRIVILEGES ON 新DB名.* TO ユーザ名@localhost IDENTIFIED BY ‘パスワード’;

nanoから出てsudo chown -R www-data:www-data /var/www/ルートディレクトリ/

今回DB名を変えたのでWordPressがアクセスするDB名も書き換え、wp-config.phpをnanoで、define( ‘DB_NAME’, ‘新DB名’ );に。

移行でドメイン名が変わるならDBの記事データ内のドメイン名も書き換え、サイトURL、home、カスタムフィールド値も書き換え。GUIDや記事タイトルは今回書き換え不要やった。作業は以下文を使用。

sudo mysql
DB選択は下記
use DB名;
UPDATE wp_posts SET post_content=REPLACE (post_content,’http://旧ドメイン名’,’https://新ドメイン名’);

上記文のwp_postsとpost_contentを下記に変えて同じように書き換え

wp_options (option_value

wp_postmeta (meta_value

これでようやく復元可能なDB出来上がりかな?まだなんかやってたかな思い出せん…

結論、マルチサイトはDBの復元が地獄。

サイトバックアップ

データベースバックアップ前に使用中のプラグインを全解除

mysqldump -h localhost -u ユーザ名 -p –databases データベース名 > ほげ.sql

データベースユーザ名のパスワード入力

データベースバックアップしたらプラグイン再適応を忘れずに

続いてプラグイン、テーマ、画像バックアップ

wp-contentのplugins、themes、uploadsをコピー

でも当方プラグインもテーマもデフォルト使用やから画像入ってるuploadsのみでヨシ。テーマのfunction.php一部書き換えてるけど冒頭数行やしnano追記でヨシ。備忘録ヨシ。

パーマリンクバグ修正

sudo nano /etc/apache2/apache2.conf

開いたら

<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

NoneをAllに変更で保存

sudo systemctl restart apache2

ubuntu-server22.04の自宅サバ、apache2.4での話

JSONリクエストに失敗して記事投稿できないバグ、パーマリンク変更で一時凌げるバグ、大抵パーマリンクの基本が使えないらしいけど今回逆で基本以外使えなかった、それでも上記作業で修正できたからヨシ。備忘録ヨシ。

object-cache.php

少し編集したobject-cache.phpを入れるだけで済ませるサイトに出会う前にいろいろ試したのが原因なのか?まるで上手くいかず記事ページ固まる、なぜなのか…

いったん保留しパーマリンクバグに立ち向かうか

まあ失敗してもバックアップの復元からやから気が楽ね

サイトヘルス気になる

永続オブジェクトキャッシュを使用してください

ページキャッシュは検出されませんでしたが、サーバーのレスポンスは良好です

調べたらキャッシュのプラグイン入れたらいいような事出てくるが削りに削ったプラグインまた増やすの嫌やな、サバ側でどうにか出来んのか調べてみるか…

APCu?APC?Alternative PHP Cache?なんなん?

サイトヘルスが気になってメンタルのヘルスが削られる現象起きてない?

さすが宅サバ、速くなったった

宅サバに移行。

プラグインとテーマを一掃しPHP7.4に上げてWordPress6.4.2に出来たので体感速度が跳ね上がりました。宅サバのハードおよび回線性能は大したモノでもないにもかかわらずここまでの向上は凄い、PHP8は更に速度向上するらしいのでなんなら今が最速でもないところがまたテンション上がる、維持費が半分以下になった点も嬉しい。

実験的にいろいろ出来るのでガンガン実験する事にします、せっかくの宅サバなので。単サバにバーチャルホストで何個もサイト組んだり何個もWordPress入れたり、手の施しようがなくなるくらい酷くして一からやり直したり…なんでも恐れず出来る。通常のブログ運営やサイト運営はまずサーバ落とさないように尽力するけど知ったこっちゃない、サバ落ちガンガンさせる、訪問してサバ落ちやエラー出て表示されない時は何かしてるなと思ってください。

手始めにPHP8.1に上げるか、手順忘れんうちに。