結論から書くと、レンタルサーバーで動く PHP システムのバックアップは、別の環境に戻して動くことを確かめて、初めて役に立ちます。保守やバージョンアップの前に、対象を洗い出し、自動バックアップとは別に自分でも取り、サーバーの外に保管し、一度戻してかかる時間を知っておきます。
この記事では、開発会社と連絡が取れないときのソースコードとデータの確保（「開発会社と連絡が取れなくなった PHP システムを引き継ぐ手順」）、PHP を切り替えて動かなくなったときの切り戻し（「レンタルサーバーで PHP のバージョンを切り替えたら動かなくなったときの切り分け」）、ホームページの月額保守の全体、データベースのバージョンアップは扱いません。
戻すために必要なものを洗い出す
IPA の「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年3月公開）は、基本の対策である情報セキュリティ6か条に「バックアップを取ろう!」を挙げ、まず対象を選ぶよう書いています（21ページ）。PHP のシステムでは、次のものが対象です。
| 対象 | 注意すること |
|---|---|
| プログラムのファイル | 公開ディレクトリの外のファイルや、ライブラリ（vendor）も含める |
| アップロードされたファイル | Laravel の標準の保存先は storage/app の下。データベースと同じ頻度で取る |
| データベース | 動いている最中に取るので、取り方に注意する |
設定ファイル（.env など） |
パスワードを含むので、見られる人を限って保管する |
| 定期処理（cron） | 何を、いつ動かしているか |
| サーバー側の設定 | PHP のバージョン、php.ini・.user.ini、.htaccess。管理画面の値は書き写す |
.env は、Laravel の公式ドキュメントがソース管理に含めないよう書いているため、コードが git（変更の履歴を管理する道具）にあっても手元に無いことがあります。また .env の APP_KEY（Laravel が暗号化に使う鍵）が変わると、それまでの鍵で暗号化したデータは復号できなくなるため、.env も取ります。
メールのアカウントや DNS（ドメインとサーバーを結びつける設定）のレコードは、ファイルに入らないので、管理画面の設定を別に控えます。
サーバー会社の自動バックアップで足りるか
自動バックアップの機能があれば、保存される世代と期間、対象の範囲（データベースやメールを含むか）、戻し方（自分で・個別に戻せるか、今のデータが上書きされるか）、戻すときの費用を、契約しているサーバーのマニュアルで確認します。
それでも、これだけには頼りません。
- 本番と同じ事業者の設備にある。 IPA の「情報セキュリティ6か条（解説編）」が紹介する「3-2-1ルール」でも、コピーの1つは稼働しているシステムとは異なる拠点などに置きます。
- 保存期間を過ぎてから問題に気づくことがある。 そのときには、正常な時点の世代が残っていない場合があります。
- 契約やアカウントの問題で、バックアップごと使えなくなるおそれがある。
自分で取る: データベースとファイル
SSH（サーバーに接続してコマンドで操作する方法）が使えるなら、データベースは mysqldump で SQL 文として書き出します。書き出したファイルをダンプと呼びます。MariaDB では mariadb-dump という名前です。
mkdir -p ~/backup && chmod 700 ~/backup
mysqldump --single-transaction --routines --events --no-tablespaces \
--default-character-set=utf8mb4 \
-h ホスト名 -u ユーザー名 -p データベース名 > ~/backup/db-20261104.sql
tail -n 1 ~/backup/db-20261104.sql
cd /path/to && tar -czf ~/backup/files-20261104.tar.gz project
crontab -l > ~/backup/crontab-20261104.txt公式ドキュメントによる、オプションの意味です。
--single-transaction: テーブルの保存方式が InnoDB なら、サイトを止めずに、取り始めた時点の状態で取ります（古い方式の MyISAM などには効きません）。取っている間は、マイグレーションなどテーブルの構造を変える操作を流しません。--routines・--events: データベースに保存した処理（ストアドプロシージャやイベント）を含めます。MySQL 8.4 では、前者にサーバー全体の SELECT 権限、後者に対象データベースの EVENT 権限が要ります。権限のエラーで止まり、そうした処理も使っていなければ外します。--no-tablespaces: 付けると PROCESS 権限が要りません。--default-character-set: データベースの文字コードに合わせます。
-p の後にパスワードは書かず、実行時に入力します。コマンドラインに書くと他の利用者に見られるおそれがあるためです。取り終えたら、最後の行が -- Dump completed on で始まるかを tail で確かめます。途中で止まっても、ファイル自体はできてしまいます。ダンプとファイルのアーカイブにはパスワードや個人情報が入ることがあるので、公開ディレクトリの外に作り、手元に移したらサーバーから消します。
SSH が使えなければ、データベースは管理画面の phpMyAdmin などから SQL 形式でエクスポートし、ファイルは FTP クライアントでダウンロード、定期処理は管理画面の設定を書き写します。.env や .htaccess のように、名前がドットで始まるファイルが取れているかも確かめます。
保管する: サーバーの外に、世代を分けて
ガイドラインの本編は、保管場所、世代の管理、保管期間を決め、遠隔地を含めた保管方法と復元の手順書を整えるよう書いています（21・33ページ）。置き場所は、契約しているサーバーの外にします。
- 世代を残す。 上書きを続けると、壊れた状態を取ったときに戻れません。何日分を残すかを決めます。
- 暗号化する。 ダンプには顧客や会員の個人情報が入ることがあります。本編も、漏えい時の影響を和らげる措置として暗号化を挙げています。
- 見られる人を決める。 アクセスできる人を一覧にし、担当者が替わったら見直します。
別の環境に復元して確かめる
6か条の解説編も、対策例に、戻せるかを定期的に確認することを挙げています。戻す先は本番ではなく、検証用のサーバーや手元の環境です。個人情報が入っている場合は、戻した環境もバックアップと同じく見られる人を限り、確認が終わったらデータを消します。
- 本番と同じバージョンの PHP とデータベースを用意する。
- ファイルを展開し、接続先を検証用に書き換える。 メールや外部サービスが本番の宛先に届かないようにし、定期処理は動かしません。Laravel で本番が設定をキャッシュ（
config:cache）していると、.envを書き換えても読み込まれないため、書き換えた後にphp artisan config:clearを実行します。 - データベースを作り、ダンプを読み込む。
mysql データベース名 < ダンプで読み込みます。 - Laravel なら
php artisan storage:linkで画像などへのリンクを作り直す。
戻したら、ログイン、主な画面、最新のデータの日時、アップロードした画像、日本語の文字化け、エラーログを確かめます。手順ごとにかかった時間も記録します。本番が壊れたときに、業務が止まる時間の目安になります。
戻し方の問題も分かります。phpMyAdmin から読み込める大きさは、FAQ のとおり PHP の upload_max_filesize などで制限されます。
h-system でできること
h-system では、他社や前任者が作った PHP・Laravel のシステムの保守・引継ぎ・バージョンアップを、開発者本人が直接お引き受けしています。資料がない状態からでも、調査だけのご依頼でも構いません。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。