さくらのクラウドのバックアップからファイルだけを復元する方法

こんにちは、UOZUです！

「誤って削除した画像を1つだけ戻したい」「変更前の設定ファイルを確認したい」といった場面で、サーバー全体をバックアップ時点に戻すと、残しておきたい変更まで巻き戻ってしまいます。

今回は、さくらのクラウドのアーカイブから別のディスクを作成し、作業用サーバーに接続してマウントするまでの方法を紹介します。

アーカイブから直接ファイルを取り出せる？

さくらのクラウドの自動バックアップは、ディスクからアーカイブを作成する機能です。公式マニュアルでは、アーカイブからファイル単位で復元することはできないと案内されています。

本記事では、まずアーカイブ全体を別ディスクへ復元し、その中にあるファイルをLinuxのコマンドでコピーします。管理画面からファイルを選択してダウンロードする機能ではありません。

ディスク全体を復元する方法は、関連記事「自動バックアップから復元する方法」で紹介しています。

自動バックアップから復元する方法｜実際の画面有りで手順を解説 | さくらのクラウドラボ by NETASSIST

さくらのクラウドで自動バックアップの設定から復元までを実機で検証。ディスクの切り替え手順や巻き戻しの挙動を実例付きで解説します。

今回の構成と前提

元サーバーのディスクはそのまま使用し、取り出し作業には別のサーバーを用意します。

1. 必要なファイルを含むアーカイブを選ぶ
2. アーカイブから復元用ディスクを作成する
3. 作業用サーバーに追加ディスクとして接続する
4. 読み取り専用でマウントする

ディスクの接続・取り外しには、接続先サーバーのシャットダウンが必要です。別の作業用サーバーを使うことで、この操作のために元サーバーを停止する必要はありません。ただし、ファイルを本番環境へ反映する際のサービス停止・再読み込みは、対象アプリケーションによって判断します。

1．復元するアーカイブを確認する

コントロールパネルで対象の自動バックアップを開き、「アーカイブ」タブから復元元を確認します。

確認するのは、対象ディスクとバックアップの日時です。ファイルを削除・変更する前のバックアップを選びましょう。取得後に作成したファイルは、そのアーカイブには含まれません。

必要な世代が自動削除されないようにする場合は、公式マニュアルの「アーカイブを世代管理の対象外にする手順」を確認します。対象の autobackup-xxxxxxxxxxxx タグを削除すると、自動削除の対象外になります。保持したアーカイブには料金がかかるため、作業後の扱いも決めておきます。

2．アーカイブから復元用ディスクを作成する

「ストレージ」→「ディスク」からディスクを追加します。ディスクソースとして対象のマイアーカイブを選択します。

作成後は、コピーが正常に完了するまで待ちます。

復元用ディスクは、保存済みの内容を読むためのものです。ブランクディスクで作り直したり、フォーマットしたりしないでください。パスワードやネットワークを書き換える「ディスク修正」も、今回の取り出し作業では行いません。

3．作業用サーバーに接続する

作業用サーバーには、新規に用意した独立したOSディスクを使います。ただし、新規作成でもイメージ由来のUUIDが残る場合があるため、別サーバーというだけでUUIDが異なるとは判断しません。復元元と作業用OSのUUIDを接続前に比較してください。復元元サーバーの複製では、UUIDやLVMの識別情報なども重複する場合があります。

ルート領域のUUIDが重複する場合、起動ディスクの順番を指定するだけでは十分とは限りません。 カーネルの起動引数やfstabがUUIDを参照していると、別のディスクを選ぶ可能性があります。最初の起動から重複を避けるには、UUIDが異なる作業用OSを用意するか、対応するレスキューISOなどから起動し、対象を特定したうえで復元用ディスクのUUIDを変更します。変更方法は次節で説明します。

まず、追加前のディスク構成を控えます。

実行先：作業用サーバー

# LANG=C lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID
NAME    SIZE TYPE FSTYPE UUID
sr0    1024M rom
vda      20G disk
|-vda1    1M part
`-vda2   20G part ext4   381c0f82-d710-400c-91fc-a66fc6f5733b

# findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/vda2 ext4   rw,relatime

その後、作業用サーバーを正常にシャットダウンします。停止を確認したら、コントロールパネルのサーバー詳細→「ディスク」タブ→「接続」から、復元用ディスクを追加します。

作業用サーバー自身のOSディスクは接続したままにし、復元用ディスクを追加ディスクとして扱います。復元用ディスクから起動しないよう、ディスクの構成と起動順を確認してから起動してください。

4．復元対象のパーティションを確認する

起動後、再度ディスク構成を確認します。

実行先：作業用サーバー

# LANG=C lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINT
NAME    SIZE TYPE FSTYPE UUID                                 MOUNTPOINT
sr0    1024M rom
vda      20G disk
|-vda1    1M part
`-vda2   20G part ext4   381c0f82-d710-400c-91fc-a66fc6f5733b /
vdb      20G disk
|-vdb1    1M part
`-vdb2   20G part ext4   381c0f82-d710-400c-91fc-a66fc6f5733b

# blkid
/dev/vda2: UUID="381c0f82-d710-400c-91fc-a66fc6f5733b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c52800d7-0585-42a0-9639-ac0e4d15fd4b"
/dev/vdb2: UUID="381c0f82-d710-400c-91fc-a66fc6f5733b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c52800d7-0585-42a0-9639-ac0e4d15fd4b"
/dev/vdb1: PARTUUID="995f2b31-2f3d-44d1-908e-0e68950596bb"
/dev/vda1: PARTUUID="995f2b31-2f3d-44d1-908e-0e68950596bb"

# findmnt /
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/vda2 ext4   rw,relatime

追加前と比較し、増えたディスクを特定します。ここからは、復元対象のファイルシステムが /dev/vdb2 にある例で説明します。

/dev/vdb2 は固定ではありません。実際に確認したデバイス名へ置き換えてください。

確認するポイントは、ディスク容量、パーティション構成、ファイルシステムの種類、現在のマウント先です。findmnt / で表示される作業用OSのルート領域と取り違えないようにします。

FSTYPE が LVM2_member、crypto_LUKS、linux_raid_member の場合は、この先の直接マウントの手順は使えません。構成に応じた復旧手順が必要です。特にLVMでは、同名VGや識別情報の重複を確認せず、一括で有効化する操作をしないでください。

同じUUIDのディスクが見つかった場合

アーカイブからディスクを複製すると、ファイルシステムのUUIDも引き継がれる場合があります。検証機の出力では、次のようにext4のUUIDが重複していました。

この出力から、現在のルート領域は/dev/vda2と読み取れます。ただし、どちらが目的の復元用ディスクかはUUIDだけでは判別できません。接続前の構成と管理画面上のディスクを照合してください。

UUID重複時に避けるのは、mount UUID=...や/dev/disk/by-uuid/...による指定です。同じ識別子が複数あるため、意図したディスクを一意に選べません。

対策A：一時的な取り出しはデバイス名を直接指定する

すでに正しいOSで起動しており、対象が/dev/vdb2と確認できた場合、ext4ではUUIDを変更せず、次節のmount -t ext4 -o ro,noload /dev/vdb2 /mnt/restoreで読み取り専用マウントする方法があります。ext4にXFS用のnouuidは指定しません。

対策B：復元用ディスクのext4 UUIDを変更する

重複を解消する場合は、元アーカイブを保持したうえで、未マウントの復元用コピーだけを変更します。これはディスクのメタデータへ書き込む操作です。読み取り専用での取り出しだけを行う場合、必須ではありません。

まず、現在のルート領域と対象の利用状態を確認します。

# findmnt -no SOURCE /
/dev/vda2

# LANG=C lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINT
NAME    SIZE TYPE FSTYPE UUID                                 MOUNTPOINT
sr0    1024M rom
vda      20G disk
|-vda1    1M part
`-vda2   20G part ext4   381c0f82-d710-400c-91fc-a66fc6f5733b /
vdb      20G disk
|-vdb1    1M part
`-vdb2   20G part ext4   381c0f82-d710-400c-91fc-a66fc6f5733b

vdbが未マウントであることを再確認し、対象が復元用の/dev/vdb2と確認出来たら、tune2fsでUUIDを変更します。

# tune2fs -U random /dev/vdb2
tune2fs 1.47.1 (20-May-2024)

-U randomはext2/ext3/ext4のファイルシステムUUIDを新しく生成する指定です。

成功後、デバイスを直接調べ、UUIDが異なることを確認します。

# blkid  /dev/vda2
/dev/vda2: UUID="381c0f82-d710-400c-91fc-a66fc6f5733b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c52800d7-0585-42a0-9639-ac0e4d15fd4b"

# blkid  /dev/vdb2
/dev/vdb2: UUID="d8cee811-f7f9-4951-84e3-2ce4be0add75" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c52800d7-0585-42a0-9639-ac0e4d15fd4b"

変更後も、次節の手順で/dev/vdb2を明示して読み取り専用マウントできます。UUIDの変更はファイルシステムの整合性を修復する操作ではありません。

※tune2fs -U randomで変更されるのは、ext4ファイルシステムのUUIDです。パーティションの識別子であるPARTUUIDは変更されません。本記事の実行例でもPARTUUIDは重複したままです。起動設定などでPARTUUIDを参照している場合は、ファイルシステムUUIDを変更するだけでは識別の曖昧さが残ります。UUID変更後も、復元用ディスクを接続したまま安易に再起動しないでください。

5．読み取り専用でマウントする

マウント先を作成し、mount コマンドでマウントします。

# mkdir -p /mnt/restore
# mount -t ext4 -o ro,noload /dev/vdb2 /mnt/restore

※ext4は ro の指定だけでもジャーナルを再生し、ディスクへ書き込む場合があります。ここでは noload を加え、ジャーナル再生を抑止します。

マウント結果を確認する

# findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/restore
/dev/vdb2 ext4 ro,relatime,norecovery

# ls -l /mnt/restore/var/www/html/
total 240
-rw-r--r--  1 apache apache   405 Feb  6  2020 index.php
-rw-r--r--  1 apache apache 19903 Jan  1  2026 license.txt
-rw-r--r--  1 apache apache  7406 Jan  9  2026 readme.html
-rw-r--r--  1 apache apache  7371 Feb 18  2026 wp-activate.php
drwxr-xr-x  9 apache apache  4096 May 22 01:00 wp-admin
-rw-r--r--  1 apache apache   351 Feb  6  2020 wp-blog-header.php
-rw-r--r--  1 apache apache  2323 Jun 14  2023 wp-comments-post.php
-rw-rw-rw-  1 apache apache  3606 Jul  6 18:10 wp-config.php
-rw-r--r--  1 apache apache  3339 Aug 12  2025 wp-config-sample.php
drwxr-xr-x  7 apache apache  4096 Jul  7 18:11 wp-content
-rw-r--r--  1 apache apache  5617 Aug  3  2024 wp-cron.php
drwxr-xr-x 35 apache apache 16384 May 22 01:00 wp-includes
-rw-r--r--  1 apache apache  2493 Apr 30  2025 wp-links-opml.php
-rw-r--r--  1 apache apache  3937 Mar 11  2024 wp-load.php
-rw-r--r--  1 apache apache 51850 Mar  1  2026 wp-login.php
-rw-r--r--  1 apache apache  8727 Apr  3  2025 wp-mail.php
-rw-r--r--  1 apache apache 32650 May  9 00:59 wp-settings.php
-rw-r--r--  1 apache apache 34621 Feb 18  2026 wp-signup.php
-rw-r--r--  1 apache apache  5214 Aug 19  2025 wp-trackback.php
-rw-r--r--  1 apache apache  3205 Nov  9  2024 xmlrpc.php

対象デバイスが正しく、オプションに ro が含まれていることを確認します。

通常、元のルートファイルシステムをマウントした場合、etc、var、home などのディレクトリを確認できます。

これでサーバ上で復元したいファイルの操作が出来るようになりました！

さいごに

今回の方法は、画像・テキスト・設定ファイルなどを取り出す場面を想定しています。その為、MariaDBやMySQLなどのデータディレクトリから一部のファイルだけをコピーしても、データベースが正常に復元できるとは限りません。

データベースを戻す場合は、DB専用のバックアップからの復元を基本とし、必要に応じて隔離環境でDB全体を復旧してからデータを取り出します。稼働中のデータディレクトリへ直接上書きする操作は、本記事の対象外です。

またファイル単位の復旧に備えるには、バックアップを取得するだけでなく、目的のファイルを読めるか、正しい権限で戻せるかまで確認しておくことが大切です。

最後までお読みいただき、ありがとうございました！