ワンぱくジュリー調査団 
QNAP製NASにWordPressで構築していたサイトがランサムウェアの影響で使えなくなりました。
まぁ、ランサム対策してたからバックアップから復旧…と思いきや、413エラーで復旧できない。
「どういうこと？」と思いながら約半年。
ようやく復旧できましたが、復旧できなかった原因が判明しました(;´Д｀)
さてさて、新入社員が入社して数ヶ月が経ちました。
そろそろ初々しかった若者たちも本性が出始めた頃ではないでしょうか！？
大して仕事も出来んくせにワシを見下すような態度（被害妄想）を取るヤツが出て来たなw
(# ﾟДﾟ)＜ナメるなよ！コチとら社会人３０年生じゃい！！
（長く社会人やってれば良いという話ではない）
スミマセン、少々取り乱しました。
まぁ、「私が日の目を見ないのは会社のせい」という盛大な責任転嫁して精神を落ち着かせます。
いや、今回はそういう話ではなく、QNAP製NASにWordPressで構築した社内マニュアルシステムがバックアップから復元できなくなったということに端を発します。
目次
ランサムウェアブームだった2025年。
私の会社も被害にあったのです。
そして、３年掛けて作り込んだHPの社内マニュアルシステムも被害を受けました。
ただ、当時の私は
「まぁ、ランサム対策してバックアップも取ってるから大丈夫っしょ！」
と気楽に考えていたのです。
しかしながら、現実は試練を与えてきたのです。
そう、バックアップから復旧できないという試練をね。
社内ネットワークの復旧に数ヶ月。
ようやく順調に過去データなどを閲覧～使用できるようになった頃、
「そろそろHPを復旧しなきゃ！」
と思い、バックアップから復旧しようとするも失敗。
「あれっ！？」
と思い、手を変え品を変えチャレンジするも失敗。
・・・
・・・・・・
・・・・・・・・・
(# ﾟДﾟ)クソがっ！！
何のためのバックアップだったのか…。
ここから深みにハマったのでした。
復元したかった拡張子qwpのバックアップデータは約 3.1GB。
HDP for WordPress上で復元ジョブを作成し、復元を実行すると、途中で失敗。
ログには次のような内容が出ていました。
「Upload file failed, code: 413」
413は、ざっくり言うと、
「送ろうとしているデータが大きすぎる」
という意味です。
バックアップデータが壊れているのか、HDPの問題なのか、WordPressの問題なのか分かりにくい。
QNAP製NASはランサムウェア対策をしているので、本来はバックアップから復旧できるはずだったのができない。
何かでブロックされている様子。
まず疑ったのは、よくあるPHP側の設定です。
WordPressで大容量ファイルを扱うときによく見る設定です。
upload_max_filesize
post_max_size
memory_limit
max_execution_time
max_input_time
今回は、これらを大きめに設定し直しました。
upload_max_filesize = 4096M
post_max_size = 4096M
memory_limit = 4096M
max_execution_time = 3000
max_input_time = 3000
3.1GBのバックアップデータなら、PHP設定上は足りているはずです。
これでも、復元は失敗しました。
つまり、問題はPHPではなさそうです。
なんかヤな感じ～。
切り分けのために、約14MBの小さいバックアップデータで復元を試しました。
ほぼ導入初期のWordPressデータ。
結果は成功。
つまり、
- HDP for WordPress自体が壊れている
- WordPress側プラグイン認証が通っていない
- 復元機能そのものが使えない
というワケではありませんでした。
小さいバックアップは成功する。
大きいバックアップだけ失敗する。
この時点で、かなりサイズ制限の線が濃くなりました。
念のため、3.1GBのバックアップデータがコピー途中で壊れていないかも確認しました。
同じバックアップデータが複数の場所に保存されていたため、MD5を比較しました。
結果は一致。
つまり、少なくともコピー途中の破損ではなさそうです。
ここまでで分かったことはこうです。
- 小さいバックアップデータは復元できる
- 3.1GBのバックアップデータだけ413で失敗する
- PHPのアップロード設定は4096Mにしている
- バックアップデータのコピー破損ではなさそう
ここまで来ると、怪しいのはPHPより前段っすね。
QNAPのサポートと一緒に探ってきた結果、最終的な原因はWordPress QPKGコンテナ内のApache Webサーバー側の制限でした。
つまり、HDPからWordPressへバックアップデータを渡すときに、PHPまで届く前にApache側で、
(;´Д｀)＜このリクエストは大きすぎるっすね～！ウチは１GBまでしかやってないんで…。
と判断されて、413で弾かれていたワケです。
PHPに届いていないので、PHP側の upload_max_filesize や post_max_size をいくら増やしても解決しません。
ここが今回のポイントでした。
対策として、Apache側に次の設定を反映しました。
LimitRequestBody 0
これは、Apache側のリクエスト本文サイズ制限を解除する設定です。
今回の場合、QNAPサポートから提供された設定ファイルをWordPress QPKGの所定位置へ配置し、WordPress QPKGを停止・起動することで反映しました。
反映後、3.1GBのバックアップデータを再度復元。
結果、無事に復元できました。
(*´Д｀)＜ワーイ（満身創痍）
今回の経験から、QNAP NASのWordPress QPKGで復元する場合、1GB以上のバックアップデータは注意した方がいいと感じました。
いや、注意しなければならない！
特に、Apache側で LimitRequestBody が明示設定されていない場合、環境によっては大容量データが413で弾かれる可能性があります。
重要なのは、WordPressやPHPだけではないということです。
大容量バックアップの復元では、少なくとも次の3か所を疑う必要があります。
今回の原因は3つ目でした。
- HDP for WordPress / MARS
- WordPress側のPHP設定
- WordPress QPKGコンテナ内のApache設定
今回のトラブルを短くまとめると、こうです。
- 現象：QNAP NASのWordPress復元で、3.1GBのバックアップデータが413エラーで失敗
- 最初に確認したこと：PHP設定、バックアップデータ破損、小さいバックアップでの復元可否
- 分かったこと：小さいバックアップデータは復元成功、大きいバックアップデータだけ413で失敗
- 原因：WordPress QPKGコンテナ内のApache側アップロード制限
- 対策：Apache設定に LimitRequestBody 0 を反映
- 結果：3.1GBのバックアップデータを復元成功、同じ症状の人への確認ポイント
今回の件で改めて思いました。
バックアップは取るだけでは足りません。
( ﾟДﾟ)＜復元できて初めてバックアップです！
しかも、WordPressのようにWebサーバー、PHP、DB、コンテナ、NASアプリが絡む構成では、エラーの原因が1か所とは限りません。
QNAP NASでWordPressを使っていて、バックアップデータが1GBを超える人は、まずはバックアップから復旧できるか試しておきましょう。
と言うことで今回はここまで！
また次回をお楽しみに(･ω･)ﾉｼ
