FJcloud実践
FJcloud-Vの「バックアップ」機能とは？仕様やメリットなどをご紹介
この記事は、ニフクラブログで2018-11-30に公開された記事を移転したものです。
こんにちは、ニフクラテクニカルアカウントチームです。
2018年9月27日にバックアップがリリースされました。
このバックアップ機能の特徴は、エージェントレスでOS領域だけではなく、増設したディスクのデータも丸ごと簡単にバックアップできるところです。
エージェントレスのため、対象のサーバー側では特に対処することなくバックアップの設定を行い実行することが可能です。
今回は、機能の仕様、メリット、注意点などについてご紹介します。
目次
前提条件
本ブログは、以下の前提知識がある方を想定しています。
- FJcloud-V(旧ニフクラ)の基本的なコントロールパネルの操作、サービスを利用する知識
(サーバー作成、ネットワーク構築など)
検証概要
- 定期バックアップができること
- バックアップデータの世代管理ができること
- 取得したバックアップデータから別サーバーとして新規作成できること
- 増設ディスクを複数利用していても問題ないこと
- 追加NICを利用していても問題ないこと
- 付替IPを利用することによりグローバルIPアドレスをリストア後も変更なく利用できること
利用リソース
今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。
※各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定の上実施しています。
検証内容
準備したリソースを使用し、バックアップデータの世代管理の確認と、リストア（別サーバーとして新規作成）するところまでの検証内容を記載します。
① バックアップルール作成
- バックアップルール作成します。
世代：２世代
増分バックアップの実行時間：14:00-16:00
※バックアップルールを作成すると、初回バックアップが実行されます。
② バックアップ実施（1世代目)
- バックアップルール作成後に初回バックアップ（フルバックアップ）が実行されます。
- 初回バックアップ完了後、「バックアップサーバー」タブにて、1世代目のバックアップデータを確認します。
- 「イベントログ」タブにて、フルバックアップ、増分バックアップのステータスが[成功]であることを確認します。
③ バックアップ実施（2世代目)
- 指定した増分バックアップの時間帯に増分バックアップが実行されます。
- 増分バックアップ完了後、「バックアップサーバー」タブにて、2世代目のバックアップデータを確認します。
※2世代目以降は変更差分のみをバックアップしておりバックアップ時間が短く性能影響が少ないです。 3. 「イベントログ」タブにて、増分バックアップのステータスが[成功]であることを確認します。
なお、本検証では3世代目の増分バックアップ前に、最新のバックアップデータとわかるようにテストファイルを作成しています。
[root@BackupServer01]# date +%Y%m%d > test.txt
[root@BackupServer01]# ls test.txt
test.txt
[root@BackupServer01]# cat test.txt
20181102
[root@BackupServer01]#
④ バックアップ実施（3世代目以降)
- 指定した増分バックアップの時間帯に増分バックアップが実行されます。
- 増分バックアップ完了後、「バックアップサーバー」タブにて、古いバックアップデータが削除され、2世代保持されていることを確認します。
※古い世代の削除タイミングが遅いときがあります。一時的に設定した世代数より多く保持しているように見えることがあります。 3. 「イベントログ」タブにて、増分バックアップのステータスが[成功]であることを確認します。
また、古い世代のバックアップデータが削除されたことを確認します。
⑤ リストア実施（別サーバーとして新規作成）
- バックアップ元サーバーから付替IPアドレスを外します。
クラウドヘルプ（付替IPアドレス：サーバーにつける・はずす） 2. バックアップ元サーバーから追加NICを外します。
**※本検証では別サーバーとして新規作成したサーバーにバックアップ元サーバーで利用していた追加NICをそのまま付与する想定のためはずしています。
新規作成したサーバー側で別途追加NICを作成し付与する場合は本手順は不要です。** 3. 対象のバックアップルール名を指定します。バックアップのプルダウンから「バックアップサーバーからのサーバーコピー」を選択し、最新のバックアップデータからリストア（別サーバーとして新規作成）します。
その際、グローバルネットワークは「付替IPアドレス」、プライベートネットワークは適切なプライベートLANを指定します。
※プライベートLANを利用していて、バックアップ元サーバーに固定でIPアドレスを設定している場合、リストア（別サーバーとして新規作成）後にIPアドレスがバッティングする可能性があるため、手動で変更してください。
※増設ディスクを含めた状態でリストア（別サーバーとして新規作成）する場合、リストア後のディスク名がランダムな文字列で作成されます。
クラウドヘルプ（バックアップ バックアップサーバーからのサーバーコピー） 4. リストア（別サーバーとして新規作成）したサーバーに追加NICの設定をします。
クラウドヘルプ（追加NIC：サーバーに設定・解除） 5. リストア（別サーバーとして新規作成）したサーバーを起動し、最新のバックアップデータからリストアされたことを確認します。
なお、本検証では3世代目のバックアップ前に作成したテストファイルが存在していることを確認しています。
[root@BackupServer01]# ls test.txt
test.txt
[root@BackupServer01]# cat test.txt
20181102
[root@BackupServer01]#
これで、バックアップデータの世代管理の確認と、リストア（別サーバーとして新規作成）するところまでの検証は完了です。
検証結果から使えそうなケース（１）
検証結果から使えそうなケースを考えてみました。
以下の要件があるサーバーには、バックアップサービスは有用です。
- 要件①：サーバーの設定変更やパッチ適用などが多く、手軽にシステムバックアップの世代管理をしたい場合
- 要件②：増設ディスク100GBを超えるようなサーバーのシステムバックアップをしたい場合 ※注意事項あり
- 要件③：サーバー障害時、システムの復旧までにかかる時間を出来るだけ短くしたい場合
- 要件④：サーバー停止時に、システムバックアップをしたい場合
検証結果から使えそうなケース（２）
バックアップサービスの仕様から、運用開始後のバックアップに使えそうです。
ただし、最大10世代(10日分)のバックアップデータしか保持できず、データのバックアップ・リストアには不向きなため、他のバックアップ機能との併用も検討が必要です。
※ワンデイスナップショットとの併用は不可となります。
注意事項について
■ バックアップルール作成
バックアップの対象となるサーバーのローカルディスク（OS領域含む）および、接続している増設ディスクの合計が1.1TBを超過するものはルールの作成が出来ません。
■ 増分バックアップ取得
バックアップ対象サーバーの更新差分量は、50GB以内が目安となります。更新差分量によっては、バックアップ処理が失敗する場合があります。
更新が多く一日で50GB以上の増分を超過する場合は、以下の運用も検討してください。
【50GBの増分が発生する前に手動実行する】
手動実行であれば一日に複数回取得することが可能です。
事前に更新がどの程度発生するか確認の上、適用を検討してください。
※10世代の制限にはカウントされます。
なお、バックアップサービスではAPIを提供しています。
APIを利用することにより、コントロールパネルにログインして実行する必要がないため、cron等でスケジューリングすることで自動化も可能となります。
※他にも注意事項があります。詳細につきましては、以下のページをご確認ください。
まとめ
新サービスのバックアップは、思っていたより簡単に利用することが出来ました。
操作自体もコントロールパネルから設定していくだけなので時間もかからず無事に完了しました。
サーバー停止時でも定期的に自動バックアップを取得することが可能なため、 タイマー機能の「サーバー停止」「サーバー起動」と組み合わせることで費用を抑えながらバックアップを取得することも出来るでしょう。
バックアップサービスには、注意事項や制限事項があるため、利用する前に十分な確認をお願いします。
