VMMからGoogleドライブへのバックアップ：スケジュールされたエクスポート、クラウド同期、および1つの名前変更スクリプト

仮想マシンと同じ NAS 上にのみ存在する VMM バックアップは、実際にはバックアップではありません。そのボックスが故障すると、両方のコピーが一緒に失われます。このストアは Synology Virtual Machine Manager の Virtual DSM ゲストとして実行され、オフサイトの VMM バックアップは、DSM に付属する 2 つの無料ツール (Virtual Machine Manager のスケジュールされたエクスポートと Google Drive へのクラウド同期) を使用して構築されています。セットアップには午後を要しました。それが静かに動作しなくなった理由を見つけるのにさらに時間がかかり、その部分がこの NAS ホスティング 101 記事が存在する理由です。以下に、動作するセットアップ、それを壊す 1 つのファイル名の癖、それを修正する小さなスクリプト、および独自のエクスポートの監査で判明した内容を示します。

SynoPower Clubポイント： どのサポートエンジニアも、バックアップが1年間正常に動作していたにもかかわらず、復元が全くできなかった顧客の話を一つや二つは持っているものだ。まさか自分の会社でそんな話を書くことになるとは思ってもみなかった。VMMのバックアップジョブはインターフェース上では完璧に正常に見えたのだが、あるホストでは1テラバイトものエクスポートファイルが蓄積され、クリーンアップが不可能になっていた。また、別のホストでは13日間もファイルが1つも生成されていなかった。何も隠蔽されていなかった。すべては誰も読まないログに記録されていたのだ。修正には1時間かかった。教訓は、他のジョブと同様に、スケジュールに従って、ファイルが実際に想定している場所に存在するかどうかを確認することだ。

完全なVMMバックアップに必要なもの #

Virtual Machine Managerは3層の保護機能を提供し、それぞれが異なる障害に対応します。優れたVMMバックアッププランでは、複数の保護機能を活用します。

層	コピーが存在する場所	何から守ってくれるのか
スナップショット	ゲストと同じ音量	ゲストOS内部のアップデートの不具合またはエラー
複製（VMM Pro）	クラスター内の別のNAS	NASの障害発生、別のホストでの迅速な復旧
スケジュールされたエクスポート + クラウド同期	オフサイトのクラウドアカウント	サイト全体の損失：火災、盗難、LAN上のランサムウェア

既に、6 つのゲストをスタンバイ ホストに複製しています。これは、当社の記事で説明されています。 3ノード構成のSynology仮想マシンクラスタレプリケーションは建物内にコピーを保持します。エクスポート層は、建物外にコピーを保持する役割を担います。

VMMのスケジュールエクスポートの仕組み #

VMMバックアップの場合、スケジュールされたエクスポートは、ゲストOS、ディスク、構成の完全なコピーを共有フォルダに単一のOVAファイルとして書き込みます。保存先フォルダ、エクスポートモード、日次、週次、月次の実行タイミング、および保持する最新ファイルの数を選択できます。エクスポートはゲストOSの実行中に実行されます。

2 つのルールは見落としやすい。まず、エクスポートはゲストのホスト上で構成され、書き込まれる。 ストレージ 実行場所ではなく、稼働場所が重要です。クラスタでは、ゲストOSは1つのNAS上で実行され、ディスクは別のNAS上に配置されることがあります。そのため、Virtual Machine Managerは間違ったホスト上でスケジュールされたエクスポートオプションをグレー表示します。次に、スケジュールはそのストレージホストのクロックを使用します。

ダイアログには、整合性状態も表示されます。ゲストOSにSynologyゲストツールがインストールされていない場合、エクスポートはクラッシュ整合性状態となり、電源コードを抜いた状態と同じになります。これはほとんどのワークロードでは問題ありませんが、ゲストツールをインストールすると、ファイルシステム整合性状態にアップグレードされます。

Cloud SyncがVMMバックアップファイルをスキップする理由 #

次に取るべき当然の手順は、Cloud Syncにエクスポートフォルダを指定し、すべてのファイルをGoogleドライブにアップロードさせることです。私たちはまさにその通りにしましたが、VMMのバックアップファイルは届きませんでした。

理由はファイル名にあります。Virtual Machine Managerは各エクスポートファイルにコロンを含むタイムスタンプを付けて名前を付けています。

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova

Cloud Sync ではこれらの名前を Google Drive にアップロードできなかったため、エクスポートされたデータはすべてローカルに保存されました。ファイル自体は有効ですが、文字に問題があります。Virtual Machine Manager ではエクスポートのタイムスタンプ形式を変更できないため、修正はエクスポートとアップロードの間に行う必要があります。

興味深いことに、タイムスタンプが付与されるのはスケジュールされたエクスポートのみです。同じメニューから手動でエクスポートした場合は、ゲスト名として保存されます。 spc_4C8G.ovaそして、Cloud Syncはそれを問題なくアップロードします。そのため、簡単な手動テストではチェーン全体が正常に見えるかもしれませんが、実際には夜間スケジュールはクラウドにアップロードされないのです。

VMMバックアップをGoogleドライブに設定する4つのステップ #

これは、ゲストOSを保存する各ホスト上で動作するVMMバックアップ設定です。Virtual Machine Manager、Cloud Sync、およびGoogleアカウントが必要ですが、VMM Proは不要です。

VMMバックアップの背後にある名前変更スクリプト #

このスクリプトはVMMバックアップチェーンの中で唯一のカスタム部分であり、2つの処理を実行します。1つ目は、完了したエクスポートファイルの名前を変更し、コロンをハイフンに置き換えること。2つ目は、エクスポートフォルダ内に各ゲストOSの最新コピーのみを保持することです。15分間変更されていないファイルのみを処理するため、書き込み中のエクスポートファイルの名前が変更されることはありません。

#!/bin/bash # vm-export-cloud.sh - VMM エクスポートを Cloud Sync でアップロードできるようにします。 # # VMM はエクスポートに名前を付けます " -YYYY-MM-DD HH:MM:SS- .ova」。Cloud Sync は「:」を含む名前をアップロードしません。つまり、書き込み中のエクスポートには一切触れません。エクスポートが完了すると、Cloud Sync が認識できるように、ファイル名を「:」から「-」に変更し、ゲストごとに最新の名前変更されたエクスポートのみを保持します。（VMM の保持機能では名前変更されたファイルを参照できなくなるため、保持はここで行われます。） 使用方法: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] --apply を指定しない場合は、実行内容のみが表示されます。 set -u DIR={1:?EXPORT_DIR}; KEEP={2:?KEEP}; APPLY={3:-} MIN_AGE_MIN=15 # 完了したエクスポートは、この間ずっと変更されていません LOG="$(dirname "$(readlink -f "$0")")/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (ドライラン) $*"; fi; } [ -d "$DIR" ] || { say "ERROR エクスポートフォルダが見つかりません: $DIR"; exit 1; } # 1. 完了したエクスポートの名前変更 find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | while IFS= read -r -d '' f; do if command -v fuser >/dev/null 2>&1 && fuser -s "$f" 2>/dev/null; then say "skip (in use): $(basename "$f")"; continue fi new="$DIR/$(basename "$f" | tr ':' '-')" say "rename: $(basename "$f") -> $(basename "$new")" run mv -n "$f" "$new" done # 2. ゲストごとに最新の名前変更されたエクスポートを保持します (タイムスタンプは名前に含まれています) { find "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\n' [ "$APPLY" = "--apply" ] || find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\n' | tr ':' '-' } | sort -u | sed -E 's/^(.*)-([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2})-.*\.ova$/\1\t\2\t&/' | awk -F'\t' 'NF==3' | sort -t$'\t' -k1,1 -k2,2r | awk -F'\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | while IFS= read -r old; do say "delete (beyond newest $KEEP): $old" run rm -f -- "$DIR/$old" done say "done: $(find "$DIR" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h "$DIR" | awk 'NR==2{print $4" free"}')""

まず、最後の引数を指定せずに実行してください。そのモードでは、名前変更と削除の対象となる項目のみが表示されます。出力が適切であれば、実行に必要な引数を追加してスケジュール設定してください。タスクスケジューラジョブは、エクスポートフォルダごとに1つのジョブとして、root権限で1時間ごとに実行されます。

bash /volume1/@vm-export-cloud/vm-export-cloud.sh "/volume3/VM_BK_Export" 3 --apply

コロンルールの便利な副次的効果として、スクリプトがファイル名を変更するまでCloud Syncはエクスポートファイルをアップロードできず、スクリプトは完了したファイルのみファイル名を変更します。書き込み途中のエクスポートファイルはクラウドにアップロードされることはありません。

スクリプトがVMMバックアップの保持を処理する理由 #

Virtual Machine Managerには独自の保持設定があり、作成された各エクスポートを記録することで機能します。スクリプトがファイルの名前を変更すると、Virtual Machine Managerはそのファイルを認識せず、削除することもありません。そのため、保持処理はスクリプト内で行われ、ファイル名に含まれるタイムスタンプからゲストごとのコピー数をカウントします。

クラウド同期に関しては、Googleドライブで何が起こるかを決定するチェックボックスが1つあります。その文言は誤解を招きやすいものです。 ソースフォルダでファイルが削除された場合、宛先フォルダ内のファイルも削除しないでください。チェックを外したままにすると、Google Drive は NAS をミラーリングし、同じ 3 つのコピーを保持します。チェックを入れると、クラウドはこれまでアップロードされたすべてのエクスポートを保存します。これはランサムウェア対策としてはより安全な選択肢ですが、手動で削除するまでファイルサイズが大きくなり続けます。

自社輸出の監査で判明したこと #

この設定を行う前は、VMMバックアップは両方の本番ホストで約1か月間稼働していました。ダッシュボードではなくファイルを確認したところ、3件の別々の障害が見つかりました。

• あるホストでデータ保持機能が静かに破損した。 Virtual Machine Managerがエクスポートを追跡するために使用する小型データベースがエクスポートフォルダ内に作成できなかったため、実行のたびにエラーがログに記録され、古いエクスポートが削除されませんでした。あるホストでは1テラバイトのOVAファイルが蓄積され、97%が満杯になりました。
• 最大の顧客企業が輸出を停止した。 84GBのエクスポートデータが残りの容量に収まらなくなったため、何の警告も表示されずに3日間連続で失敗しました。
• どこにも繋がらない3つのスケジュール。 設定変更により、3つのエクスポートスケジュールの保存先が空になってしまいました。それ以降、1分ごとに無効な共有名がログに記録され、その回数は2万回を超え、この店舗のスケジュールを含め、何もエクスポートされなくなりました。

通常の使用状況では、これらの問題はVMMバックアップの障害として認識されませんでした。ゲストOSは稼働し、ストアは注文を受け付け、レプリケーションによってスタンバイホスト上にコピーが保持されていました。唯一のオフサイトコピーであるエクスポートレイヤーが停止していただけだったのです。今後は、スケジュール変更のたびにエクスポートフォルダとクラウド同期アップロードリストを確認するようにしています。

VMMバックアップのための帯域幅とストレージの計画 #

VMMのバックアップエクスポートはすべて増分コピーではなく完全コピーなので、スケジュールを選択する前にサイズを確認してください。当社のゲストは5GBの小規模ウェブサイトから84GBのパートナーウェブサイトまで様々で、このストア自身のエクスポートは約7GBです。すべてのゲストを合わせると、毎日のスケジュールでは1日に100GB以上がアップロードされます。

Google Driveでは、各ユーザーが24時間以内に最大750GB、ファイルサイズは最大5TBまでアップロードできるため、容量制限が問題になることはほとんどありません。問題となるのはアップロード時間とクラウドストレージです。クラウドに各ゲストの3つのコピーを保持するには、1日の合計容量の3倍のドライブ容量が必要となり、すべてのコピーをクラウドに保存する場合はさらに多くの容量が必要になります。大規模で変更頻度の低いゲストの場合、特にレプリケーションによって日々の復旧が既にカバーされている場合は、週に1回のエクスポートで十分な場合が多いです。

Synologyツールでバックアップを作成する理由 #

このVMMバックアップチェーンの構成要素はすべてDSMに付属しています。Virtual Machine ManagerがゲストOSをエクスポートし、Cloud Syncがアップロード、タスクスケジューラがスクリプトを実行し、同じNASユニットがファイルの保存とストアの実行を行います。ゲストOSごとにライセンスが必要なバックアップエージェントはなく、別途バックアップサーバーを管理する必要もありません。

私たちが料金を支払うのは、ホスト間の保護を追加する部分です。 VMM Proライセンス スタンバイへのレプリケーションのため、 Virtual DSMライセンス DSMのゲスト向け。どのエディションが必要か迷っている場合は、 Virtual Machine ManagerとVMM Proの比較 それをカバーする。

VMMバックアップの制限事項と注意事項 #

エクスポートとは、ある時点における完全なコピーを作成することです。ゲストツールを使用しない場合、クラッシュ整合性が保たれるため、ゲスト内のデータベースは停電後と同様に復旧します。最も重要なゲストの復元テストを少なくとも一度は実行してください。

クラウドからVMMバックアップを復元するには、まずファイル全体をダウンロードする必要があります。84GBのエクスポートは、一般的なオフィス回線では数時間かかるため、クラウドコピーは災害時のみに使用し、日常的なミスには適していません。スナップショットやレプリケーションの方がはるかに高速に処理できます。

Cloud Syncはアップロード前にファイルを暗号化できるため、顧客データを含むゲストOSではこの機能を有効にすることをお勧めします。暗号化パスワードは、保護対象のNASに依存しない場所に保管してください。

最後に、名前変更スクリプトはエクスポート名のフォーマットに依存しています。今後のVirtual Machine Managerアップデートでフォーマットが変更されると、スクリプトはファイルのマッチングを停止します。ドライランモードは、アップデート後もエクスポートが正しく認識されることを確認する最も簡単な方法です。

よくある質問 #

参考資料とビデオチュートリアル #

• Virtual Machine Manager の仮想マシン輸出に関するナレッジセンターの記事。
• クラウド同期のヘルプ同期方向やタスク設定なども含まれます。
• Googleドライブのストレージとアップロードの制限1日のアップロード制限は750GBです。
• Synology VMM ホワイトペーパー仮想マシンのデータ保護レイヤーについて。
• DSMのタスクスケジューラ名前変更スクリプトをスケジュールされたタスクとして実行する場合。

この一連のツールに関するビデオ：クラウド同期、およびSynology NAS上での仮想マシンのエクスポートと移行。

オフサイトコピーに加えてホスト間のレプリケーションを追加したいですか？ VMM Proライセンスまたは、このサイトの残りの部分がどのように動作するかを読んでください NASホスティング入門シリーズ.