rsync –delete を使った本番へのデプロイで、消えると困るファイルをどう見分けるか

2026年9月14日

URLをコピーしました！

rsyncでファイルを転送するとき、--delete オプションを使うと、送り元にないファイルが送り先から削除されます。古いファイルを残さず本番を同期できるので、WordPressのアップグレード後の反映などで重宝します。

ただしこのオプションは、本番にしか存在しないファイルも消します。 サーバーが生成した設定ファイルや、後から追加した認証用ファイルなどです。

今回は、その代表例であるXserverの .user.ini を軸に、「消えると困るファイル」をどう見分けるかを整理します。

前提：`--delete` は何を消すのか

まず動作を確認しておきます。

rsync -avz --delete \
  --exclude 'wp-config.php' \
  --exclude 'wp-content/uploads' \
  /path/to/local/ \
  server:path/to/production/

--delete を付けると、rsyncは送り元と送り先を比較して、送り先にしかないファイルを削除します。

WordPressのバージョンを上げると、不要になるコアファイルが出てきます。これを残しておくと不具合の原因になるので、--delete で掃除するのは理にかなっています。

問題は、rsyncには「これはサーバーの設定ファイルだから残そう」といった判断ができないことです。送り元にないものは、等しく削除対象になります。

削除リストを先に確認する

なので、実行前に必ず何が消えるかを見ます。-n（dry-run）を付けると、実際には転送せず結果だけを表示します。

rsync -avzn --delete ... | grep deleting

grep deleting で削除される分だけを抜き出せます。転送されるファイルは大量に出るので、削除リストだけ見るほうが確認しやすいです。

このリストに見覚えのないファイルがあれば、そこで一度止まる。これが今回の主題です。

具体例：Xserverの `.user.ini`

実際に削除リストへ出てきたのが、.htaccess と .user.ini でした。

.htaccess は誰でも警戒すると思います。Apacheの設定ファイルで、リダイレクトやアクセス制限が書かれています。

一方 .user.ini は、存在自体を知らない人もいるかもしれません。しかも今回は、紛らわしい状況になっていました。

セキュリティプラグインの記述と紛らわしい

.htaccess の中身を見ると、こうなっていました。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# BEGIN WordPress
（WordPressが自動生成するパーマリンク用の記述）
# END WordPress

# セキュリティプラグインが追加したブロック
<Files ".user.ini">
（.user.iniへの外部アクセスを禁止する記述）
</Files>

末尾に、セキュリティプラグインが .user.ini を保護する記述を追加しています。「外部から .user.ini を読めないようにする」という内容です。

この並びだけを見ると、.user.ini 自体もそのプラグインが生成したファイルに見えます。プラグインを削除したのだから、関連ファイルも消してよい、と判断してしまいそうな状況です。

中身を見れば分かる

実際には違います。中を確認してみます。

cat .user.ini

[PHP]
engine = On
default_charset = UTF-8

error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
display_errors = On

max_execution_time = 180
memory_limit = 1G

post_max_size = 1G
upload_max_filesize = 1G

[mbstring]
mbstring.language = Japanese
mbstring.internal_encoding = UTF-8

[Date]
date.timezone = "Asia/Tokyo"

[Session]
session.save_path = "/home/サーバーID/ドメイン名/xserver_php/session"
（以下、数百行）

決定的なのは session.save_path です。サーバーIDとドメイン名を含むパスが書かれています。プラグインがこんなパスを知っているはずがありません。

さらに xserver_php というディレクトリ名まで入っています。ここまで来れば、Xserverが生成したファイルだと断定できます。

`.user.ini` とは何か

PHPの設定ファイルです。php.ini がサーバー全体の設定であるのに対して、.user.ini はディレクトリ単位で設定を上書きできる仕組みになっています。

Xserverの場合、サーバーパネルの「php.ini設定」で変更した内容が、このファイルに書き出されます。つまりGUIで設定した内容の実体がこれです。

削除するとどうなるか。設定がすべてデフォルトに戻ります。

memory_limit = 1G → デフォルト値へ
upload_max_filesize = 1G → デフォルト値へ
date.timezone = "Asia/Tokyo" → 未設定に

WordPressは重いプラグインやテーマを動かすとメモリを消費します。memory_limit が下がれば、管理画面が白くなったり、画像のアップロードに失敗したりする。

しかも厄介なのは、エラーの原因が設定ファイルの削除だと気づきにくいことです。.htaccess を消したなら心当たりがありますが、.user.ini は存在を知らなければ疑いようがありません。

見分ける基準

今回のケースから、判断基準を整理しておきます。

原則

「ローカルに存在せず、本番にのみ存在するファイル」は、まずサーバー固有の設定とみなす。

--delete で危険なのは、この種類のファイルです。ローカルにないので、rsyncからは「余計なファイル」に見える。しかし実際には、そのサーバーで動くために必要なものかもしれません。

中身から判断する

削除リストに見慣れないファイルがあったら、中を見てください。次のような特徴があれば、サーバー生成の可能性が高いです。

サーバーIDやドメイン名を含むパスが書かれている
ホスティング会社の名前が入っている（xserver_php など）
自分が書いた覚えのない設定が並んでいる

逆にプラグインが生成したファイルなら、そのプラグイン名がディレクトリ名やコメントに入っていることが多いです。

警戒すべきファイル

よくあるものを挙げておきます。

ファイル	内容	消すとどうなるか
`.htaccess`	Apacheの設定	リダイレクトやアクセス制限が消える
`.user.ini`	PHPの設定（Xserver等）	メモリ上限などがデフォルトに戻る
`robots.txt`	クローラー制御	意図しないページがインデックスされる
`ads.txt`	広告の認証	広告配信が止まる可能性がある
`google*.html`	Search Console認証	サイト所有権の確認が外れる
`favicon.ico`	ファビコン	表示されなくなる

このうち .user.ini は特に厄介です。存在を知らないと、消したこと自体に気づけません。

疑わしければ残す

判断がつかないなら、除外リストに入れて残すのが安全です。

余計なファイルが残っても、たいていは無害です。一方、必要なファイルを消すと、サイトが動かなくなったり、原因不明の不具合が出たりする。リスクが対称ではありません。

除外設定

結論としては、これらを除外リストに加えます。

rsync -avz --delete \
  --exclude 'wp-config.php' \
  --exclude '.htaccess' \
  --exclude '.user.ini' \
  --exclude 'robots.txt' \
  --exclude 'wp-content/uploads' \
  /path/to/local/ \
  server:path/to/production/

.htaccess を除外するかは考え方が分かれます。ローカルで管理して本番に反映する運用もありますが、私は除外する方を選びました。本番にはBasic認証やIP制限を後から追加することがあるので、デプロイのたびに上書きされる仕組みだと事故ります。

サーバー側で管理するファイルは、サーバー側に置いたままにする。 これが一番トラブルが少ないと思います。