効果的なバックアップ戦略の選択方法

はじめに

バックアップはクラウドサーバーにとって非常に重要です。1つのプロジェクトを実行してすべてのデータを1つのサーバーに保存している場合や、Gitから直接VMに展開して最小限のログを保持しながらスピンアップおよびスピンダウンされる場合でも、常に障害発生シナリオを想定して計画する必要があります。使用しているアプリケーションや、即時のフェールオーバーがどれだけ重要か、どのような問題が予測されているかに応じて、これはさまざまなことを意味します。

このガイドでは、バックアップとデータ冗長性の提供方法についてさまざまなアプローチを探ります。異なるユースケースには異なる解決策が求められるため、この記事では一括解決策を提供することはできませんが、さまざまなシナリオで重要なポイントと、運用に最適な実装方法について学ぶことができます。

このガイドの第1部では、いくつかのバックアップソリューションを検討し、それぞれの相対的な利点を見て、環境に適したアプローチを選択できるようにします。第2部では、冗長性オプションを探ります。

第1部 — 冗長性とバックアップの違いは何ですか？

冗長とバックアップの定義はしばしば重なり合い、多くの場合、混同されます。これらは関連するが異なる2つの概念です。一部のソリューションは両方を提供しています。

冗長性

データの冗長性は、システムの問題が発生した場合にすぐにフェイルオーバーがあることを意味します。フェイルオーバーとは、1つのデータセット（または1つのホスト）が利用できなくなった場合、別の完全なコピーがすぐに本番環境に交換され、その場所を埋めます。これにより、ほとんど感知できないダウンタイムで、アプリケーションまたはウェブサイトは何も起こっていないかのようにリクエストを処理し続けることができます。その間に、システム管理者（この場合はあなた）は問題を修正し、システムを完全に稼働可能な状態に戻す機会があります。

ただし、冗長性のソリューションは通常、バックアップのソリューションでもありません。冗長なストレージは、通常、マシンまたはシステム全体に影響を与える障害からの保護を提供しません。たとえば、ミラーリングされたRAIDが構成されている場合（RAID 1など）、データは冗長性がありますが、1つのドライブが故障した場合、他のドライブは引き続き利用可能です。ただし、マシン自体が故障した場合、すべてのデータが失われる可能性があります。

冗長性のソリューション、例えばMySQL Group Replicationのように、通常はデータの各コピーで行われるすべての操作が含まれます。これには悪意のあるまたは偶発的な操作も含まれます。定義上、バックアップソリューションはデータが正常であると知られている以前のポイントからの復元を許可する必要があります。

バックアップ

一般的に、重要なデータの機能的なバックアップを維持する必要があります。状況に応じて、これはアプリケーションやユーザーデータ、またはウェブサイトやマシン全体のバックアップになる可能性があります。バックアップの考え方は、システム、マシン、またはデータの損失が発生した場合に、データにアクセス、再展開、またはそれ以外のアクセスができるようにすることです。バックアップからの復元にはダウンタイムが必要ですが、1日前から始めるか、最初から始めるかの違いを意味することができます。失うことができないものは、定義上、バックアップされる必要があります。

方法に関しては、バックアップの異なるレベルがいくつかあります。これらは、さまざまな種類の問題に対応するために必要に応じてレイヤー化することができます。例えば、構成ファイルを変更する前にバックアップして、問題が発生した場合に古い設定に戻すことができます。これは、積極的に監視している小さな変更に最適です。しかし、この設定はディスク障害やそれ以上の複雑な問題の場合には失敗します。定期的かつ自動的なバックアップをリモートロケーションにも持っているべきです。

バックアップ自体は自動フェイルオーバーを提供しません。これは、バックアップが100%最新であると仮定すると、データには影響がないかもしれませんが、稼働時間に影響を与える可能性があります。これは、冗長性とバックアップがしばしば組み合わせて使用される理由の1つです。

パート2 — ファイルレベルのバックアップ

バックアップの最も一般的な形態の1つは、ファイルレベルのバックアップです。このタイプのバックアップでは、通常のファイルシステムレベルのコピー手段を使用してファイルを別の場所やデバイスに転送します。

cpコマンドの使用方法

理論上、Linuxマシン（クラウドサーバーなど）をcpコマンドでバックアップすることができます。これは、ファイルをローカルの場所から別の場所にコピーします。ローカルコンピューターでは、リムーバブルドライブをマウントし、その後ファイルをコピーできます:

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

この例では、リムーバブルディスクsdcを/mnt/my-backupとしてマウントし、/etcディレクトリをディスクにコピーします。そして、ドライブをアンマウントし、別の場所に保存できます。

Rsyncの使用方法

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvPは典型的なRsyncオプションのセットです。それぞれの機能を以下に分解します：

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

他のrsyncオプションは、そのmanページで確認できます。

もちろん、クラウド環境では通常、マウントされたディスクにファイルをマウントしてコピーすることはありません。RsyncはSSHスタイルの構文を提供することで、ネットワークを介したリモートバックアップも実行できます。これは、両端にRsyncがインストールされている限り、SSHでアクセスできるホストで動作します。RsyncはコアなLinuxツールと見なされているため、これはほぼ常に安全な仮定です。たとえ、MacやWindowsマシンでローカルで作業している場合でもです。

rsync -azvP /etc/* username@remote_host:/backup/

これにより、ローカルマシンの/etcディレクトリがremote_hostの/backupにバックアップされます。このディレクトリに書き込み許可があり、利用可能なスペースがある場合、成功します。

また、ローカルとリモートのディレクトリを同期する方法に関する詳細情報も確認できます。

他のバックアップツールの使用方法

cp と rsync は便利で普及していますが、それら単独では完全なソリューションではありません。Rsync を使用してバックアップを自動化するには、独自の自動化手順、バックアップスケジュール、ログのローテーションなどを作成する必要があります。これは、外部サービスの利用を希望しない非常に小規模な展開や、非常に細かいスクリプトを維持するための専用リソースを持つ非常に大規模な展開に適しているかもしれませんが、多くのユーザーは専用のバックアップオファリングに投資したいと考えるかもしれません。

Bacula

Bacula は、クライアント – サーバーモデルで動作する複雑で柔軟なソリューションです。Bacula は、クライアント、バックアップ先、およびディレクター（実際のバックアップを指揮するコンポーネント）の概念を分離して設計されています。また、それぞれのバックアップタスクを「ジョブ」と呼ばれる単位に構成します。

これにより、非常に細かく柔軟な構成が可能になります。複数のクライアントを1つのストレージデバイスにバックアップしたり、1つのクライアントを複数のストレージデバイスにバックアップしたり、ノードを追加したり詳細を調整したりしてバックアップスキームを変更できます。ネットワーク環境での動作が良好であり、拡張性がありモジュール式であるため、複数のサーバーにまたがるサイトやアプリケーションのバックアップに適しています。

Duplicity

Duplicity はもう1つのオープンソースのバックアップツールです。デフォルトでは GPG 暗号化を使用して転送します。

ファイルバックアップにGPG暗号化を使用する明らかな利点は、データが平文で保存されないことです。GPGキーの所有者だけがデータを復号化できます。これにより、データが複数の場所に保存されている場合に必要な追加のセキュリティ対策を相殺するある程度のセキュリティが提供されます。

定期的にGPGを使用しない人々には明白ではないもう1つの利点は、各トランザクションが完全に正確であることを確認する必要があるということです。GPGは、Rsyncと同様に、ハッシュチェックを強制してデータ転送中のデータ損失がないことを確認します。つまり、バックアップからデータを復元する際に、ファイルの破損に遭遇する可能性が大幅に低くなります。

Part 3 — ブロックレベルバックアップ

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

ブロックレベルバックアップの利点の1つは、通常よりも高速であることです。ファイルベースのバックアップでは通常、各個別のファイルごとに新しい転送が開始されますが、ブロックベースのバックアップではブロックが転送され、非連続の転送が少なくなります。

ブロックレベルバックアップを実行するためのddの使用

ブロックレベルのバックアップを実行する最も一般的な方法は、ddユーティリティを使用することです。 ddは、完全なディスクイメージを作成するために使用でき、CDやDVDなどのリムーバブルメディアをアーカイブする際にもよく使用されます。これは、事前の手順なしにパーティションやディスクを単一のファイルまたは生デバイスにバックアップできることを意味します。

ddを使用するには、次のように入力場所と出力場所を指定する必要があります：

dd if=/path/of/original/device of=/path/to/place/backup

このシナリオでは、if=引数が入力デバイスまたは場所を指定します。 of=引数は出力ファイルまたは場所を指定します。これらを混同しないように注意してください。さもないと、間違ってディスク全体を消去してしまう可能性があります。

たとえば、ドキュメントが含まれているパーティション（/dev/sda3にある）のバックアップを作成するには、.imgファイルへの出力パスを指定してそのディレクトリのイメージを作成できます：

dd if=/dev/sda3 of=~/documents.img

パート4 — バックアップのバージョニング

データのバックアップの主な動機の1つは、不要な変更や削除の場合にファイルの以前のバージョンを復元できるようにすることです。これまでに言及したすべてのバックアップメカニズムがこれを提供できる一方で、より細かい解決策を実装することもできます。

たとえば、これを達成する手動の方法の1つは、nanoで編集する前にファイルのバックアップを作成することです。

cp file1 file1.bak
nano file1

このプロセスを自動化することもできます。エディタでファイルを変更するたびにタイムスタンプ付きの隠しファイルを作成します。たとえば、~/.bashrc ファイルにこれを配置して、nano を bash シェルから実行するたびに、年(%y)、月(%m)、日(%d)などでバックアップが自動的に作成されるようにします。

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

これは、手動でnanoを使用してファイルを編集する範囲内では機能しますが、制限されており、すぐにディスクを満たす可能性があります。編集するファイルを手動でコピーするよりも悪化する可能性があることがわかります。

この設計に固有の問題の多くを解決する代替案は、バージョン管理システムとしてGitを使用することです。主にプレーンテキスト、通常はソースコード、行ごとにバージョニングするために開発されましたが、Gitを使用してほぼあらゆる種類のファイルを追跡することができます。詳細については、Gitの効果的な使用方法 を参照してください。

Part 5 — サーバーレベルのバックアップ

ほとんどのホスティングプロバイダーは、独自のオプションとしてバックアップ機能を提供しています。DigtalOceanのバックアップ機能は、このサービスを有効にしているドロップレットに定期的に自動バックアップを実行します。これを有効にするには、ドロップレットの作成時に「バックアップ」チェックボックスをオンにします。

これにより、クラウドサーバーのイメージ全体が定期的にバックアップされます。これは、バックアップから再展開したり、新しいドロップレットの基盤として使用したりできることを意味します。

システムの単発イメージングを行う場合は、スナップショットも作成できます。これらはバックアップと同様の方法で機能しますが、自動化されていません。一部の状況では実行中のシステムのスナップショットを取ることが可能ですが、ファイルシステムへの書き込み方法によっては、推奨されない場合もあります。

これに関する詳細は、コンテナとイメージのドキュメントで確認できます。

GitOps

最後に、サーバーごとにバックアップを実装する必要がない場合があることに注意する価値があります。たとえば、展開がGitOpsの原則に従っている場合、個々のクラウドサーバーの多くを使い捨てとして扱い、その代わりにGitリポジトリのようなリモートデータソースをデータの実質的な真実の源として扱うことがあります。このような複雑でモダンな展開は、多くの場合、スケーラブルで障害に強い場合があります。ただし、データストア自体や、これらの使い捨てサーバーの各々が情報を送信している中央のログサーバーのために、引き続きバックアップ戦略を実装する必要があります。デプロイメントのどの側面がバックアップされる必要がないか、どれが必要かを検討してください。

結論

この記事では、さまざまなバックアップの概念とソリューションについて探究しました。次に、冗長性を有効にするソリューションを検討してみてください。