効果的なバックアップ戦略を選択する方法

序章

バックアップはクラウドサーバーにとって非常に重要です。 すべてのデータを単一のサーバーに保存して単一のプロジェクトを実行している場合でも、最小限のログセットを保持しながらスピンアップおよび分解されたVMにGitから直接デプロイしている場合でも、常に障害シナリオを計画する必要があります。 これは、使用しているアプリケーション、即時フェイルオーバーを行うことの重要性、および予想している問題の種類に応じて、さまざまな意味を持ちます。

このガイドでは、バックアップとデータの冗長性を提供するためのさまざまなアプローチについて説明します。 さまざまなユースケースでさまざまなソリューションが必要になるため、この記事では万能の答えを出すことはできませんが、さまざまなシナリオで何が重要であり、どの実装が運用に最も適しているかを学びます。

このガイドの最初の部分では、いくつかのバックアップソリューションを確認し、それぞれの相対的なメリットを確認して、環境に適したアプローチを選択できるようにします。 パート2では、冗長性オプションについて説明します。

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

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

冗長性

データの冗長性は、システムに問題が発生した場合に即座にフェイルオーバーが発生することを意味します。 フェイルオーバーとは、1セットのデータ（または1つのホスト）が使用できなくなった場合に、別の完全なコピーがすぐに本番環境にスワップされて代わりになることを意味します。 これにより、知覚できるダウンタイムはほとんど発生せず、アプリケーションまたはWebサイトは、何も起こらなかったかのように要求を処理し続けることができます。 その間、システム管理者（この場合はあなた）は問題を修正し、システムを完全に動作可能な状態に戻す機会があります。

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

MySQL Group Replication などの冗長ソリューションでは、通常、すべての操作がデータのすべてのコピーに対して実行されます。 これには、悪意のある、または偶発的な操作が含まれます。 定義上、バックアップソリューションでは、データが良好であることがわかっている以前のポイントから復元することもできます。

バックアップ

一般に、重要なデータの機能バックアップを維持する必要があります。 状況によっては、これはアプリケーションやユーザーデータ、またはWebサイトやマシン全体のバックアップを意味する場合があります。 バックアップの背後にある考え方は、システム、マシン、またはデータが失われた場合に、データを復元、再デプロイ、またはその他の方法でアクセスできるということです。 バックアップからの復元にはダウンタイムが必要になる場合がありますが、1日前から開始する場合と最初から開始する場合の違いを意味する場合があります。 失うわけにはいかないものは、定義上、バックアップする必要があります。

メソッドに関しては、かなりの数の異なるレベルのバックアップがあります。 これらは、さまざまな種類の問題を説明するために、必要に応じて階層化できます。 たとえば、問題が発生した場合に古い設定に戻すことができるように、構成ファイルを変更する前にバックアップすることができます。 これは、積極的に監視している小さな変更に最適です。 ただし、このセットアップは、ディスク障害またはより複雑な場合に失敗します。 また、リモートロケーションへの定期的な自動バックアップも必要です。

バックアップ自体は自動フェイルオーバーを提供しません。 これは、障害によってデータが失われることはないかもしれませんが（バックアップが100 % u p-to-dateであると仮定）、稼働時間がかかる可能性があることを意味します。 これが、冗長性とバックアップが互いに組み合わせて使用されることが多い理由の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の使用方法

に代わるより良い方法 cp それは rsync 指図。 Rsyncは、チェックサム検証やその他の機能が組み込まれた、さまざまな環境でファイルやディレクトリを複製するためのさまざまなオプションを提供する強力なツールです。 Rsyncは同等の機能を実行できます cp 上記のような操作：

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

-azvP Rsyncオプションの典型的なセットです。 それらのそれぞれが行うことの内訳として：

• a このコピー操作で「アーカイブモード」を有効にします。これにより、ファイルの変更時間や所有者などが保持されます。 また、それぞれを提供することと同等です。 -rlptgoD オプションを個別に（はい、本当に）。 特に、 -r オプションは、ネストされたファイルとフォルダーもコピーするためにサブディレクトリに再帰するようにRsyncに指示します。 このオプションは、次のような他の多くのコピー操作に共通です。 cp と scp.
• z 可能であれば、転送自体の間にデータを圧縮します。 これは、低速接続を介した転送、特にログやその他のテキストなど、非常に効果的に圧縮されるデータを転送する場合に役立ちます。
• v 詳細モードを有効にするので、転送の進行中に転送の詳細を読むことができます。
• P 転送を後で再開できるように、完全に転送されないファイルの部分的なコピーを保持するようにRsyncに指示します。

他のrsyncオプションは、そのマニュアルページで確認できます。

もちろん、クラウド環境では、通常、マウントされたディスクにファイルを毎回マウントおよびコピーすることはありません。 Rsyncは、SSHスタイルの構文を提供することにより、ネットワーク経由でリモートバックアップを実行することもできます。 これは、Rsyncが両端にインストールされている限り、SSHで接続できるすべてのホストで機能します。 RsyncはコアLinuxツールと見なされているため、MacまたはWindowsマシンでローカルに作業している場合でも、これはほとんどの場合安全な前提です。

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

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

Rsyncを使用してローカルディレクトリとリモートディレクトリを同期する方法の詳細を確認することもできます。

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

それでも cp と rsync 便利でユビキタスですが、それだけでは完全なソリューションではありません。 Rsyncを使用してバックアップを自動化するには、独自の自動化された手順、バックアップスケジュール、ログローテーションなどを作成する必要があります。 これは、外部サービスを利用したくない非常に小規模な展開や、さまざまな目的で非常にきめ細かいスクリプトを維持するための専用リソースを備えた非常に大規模な展開に適している場合がありますが、多くのユーザーは専用のバックアップ製品に投資することをお勧めします。

Bacula

Baculaは、クライアントサーバーモデルで機能する複雑で柔軟なソリューションです。 Baculaは、クライアント、バックアップの場所、およびディレクター（実際のバックアップを調整するコンポーネント）の個別の概念で設計されています。 また、各バックアップタスクを「ジョブ」と呼ばれる単位に構成します。

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

二枚舌

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

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

GPGを定期的に使用しない人には明らかではないかもしれない別の利点は、各トランザクションが完全に正確であることを検証する必要があることです。 Rsyncと同様に、GPGはハッシュチェックを実施して、転送中にデータが失われていないことを確認します。 これは、バックアップからデータを復元するときに、ファイルの破損が発生する可能性が大幅に低くなることを意味します。

パート3—ブロックレベルのバックアップ

少し一般的ではありませんが、ファイルレベルのバックアップの重要な代替手段はブロックレベルのバックアップです。 このスタイルのバックアップは、デバイス全体の複製と復元に使用できるため、「イメージング」とも呼ばれます。 ブロックレベルのバックアップを使用すると、ファイルよりも深いレベルでコピーできます。 ファイルベースのバックアップでは、file1、file2、およびfile3がバックアップ場所にコピーされる場合がありますが、ブロックベースのバックアップシステムでは、これらのファイルが存在する「ブロック」全体がコピーされます。 同じ概念を説明する別の方法は、ブロックレベルのバックアップが情報をビットごとにコピーすると言うことです。 彼らはそれらのビットにまたがる可能性のあるファイルについて知りません。

ブロックレベルのバックアップの利点の1つは、通常は高速であるということです。 ファイルベースのバックアップは通常、個別のファイルごとに新しい転送を開始しますが、ブロックベースのバックアップはブロックを転送します。つまり、コピーを完了するために開始する必要のある非順次転送が少なくなります。

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

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

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

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

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

たとえば、次の場所にあるドキュメントを含むパーティションをバックアップするには /dev/sda3、への出力パスを提供することにより、そのディレクトリのイメージを作成できます。 .img ファイル：

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

パート4—バックアップのバージョン管理

データをバックアップする主な動機の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を使用することです。 これは主にプレーンテキスト（通常はソースコード）を1行ずつバージョン管理することに重点を置いて開発されましたが、Gitを使用してほぼすべての種類のファイルを追跡できます。 詳細については、Gitを効果的に使用する方法を確認してください。

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

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

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

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

DigitalOceanのバックアップとスナップショットの詳細については、 Containers andImagesのドキュメントを参照してください。

GitOps

最後に、サーバーごとにバックアップを実装することを必ずしも検討していない状況があることに注意してください。 たとえば、デプロイが GitOps の原則に従っている場合、個々のクラウドサーバーの多くを使い捨てとして扱い、代わりにGitリポジトリなどのリモートデータソースをデータの有効な正しい情報源として扱うことができます。 このような複雑で最新のデプロイメントは、よりスケーラブルであり、多くの場合、失敗する可能性が低くなります。 ただし、データストア自体、またはこれらの使い捨てサーバーのそれぞれが情報を送信する可能性のある集中ログサーバーのバックアップ戦略を実装する必要があります。 展開のどの側面をバックアップする必要がないか、どの側面をバックアップする必要があるかを検討してください。

結論

この記事では、さまざまなバックアップの概念とソリューションについて説明しました。 次に、冗長性を有効にするのソリューションを確認することをお勧めします。