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

紹介

バックアップはクラウドサーバーにとって非常に重要です。単一のサーバーにすべてのデータが保存された単独のプロジェクトを運営している場合でも、最小限のログを保持しながら生成されては削除されるVMに直接Gitからデプロイする場合でも、常に障害シナリオを計画すべきです。これは、使用しているアプリケーション、即時フェイルオーバーがどれほど重要か、そして予想される問題の種類に応じて、さまざまな意味を持つ可能性があります。

このガイドでは、バックアップとデータ冗長性を提供するためのさまざまなアプローチを探ることができます。異なるユースケースには異なるソリューションが必要なため、この記事ではすべてのケースに合う答えを提供することはできませんが、異なるシナリオで重要な点と、自分の運用に最適な実装について学ぶことができます。

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

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

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

冗長性

データの冗長性は、システムの問題が発生した場合に即座のフェイルオーバーがあることを意味します。フェイルオーバーとは、一つのデータセット（またはホスト）が利用できなくなった場合に、別の完璧なコピーが即座に本番環境に切り替えられて、その位置を引き継ぐことを指します。この結果、ほとんど認識できないダウンタイムが発生し、アプリケーションやウェブサイトは何事もなかったかのようにリクエストを処理し続けることができます。その間に、システム管理者（この場合はあなた）は、問題を修正し、システムを完全に稼働している状態に戻す機会を得ることができます。

しかし、冗長性の解決策は通常、バックアップの解決策ではありません。冗長ストレージは、全体の機械やシステムに影響を与える障害からの保護を必ずしも提供しません。例えば、ミラーリングされたRAID（RAID 1など）を構成している場合、1台のドライブが故障してももう1台が利用可能なため、データは冗長です。しかし、機械自体が故障した場合、すべてのデータが失われる可能性があります。

MySQLグループレプリケーションのような冗長性ソリューションでは、通常、すべてのデータのコピーに対してすべての操作が行われます。これには、悪意のある操作や偶発的な操作も含まれます。バックアップソリューションは、データが良好であることが知られている以前のポイントからの復元を可能にする必要があります。

バックアップ

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

方法に関しては、さまざまなレベルのバックアップがあります。これらは、異なる種類の問題に対応するために必要に応じて重ねることができます。たとえば、設定ファイルを変更する前にバックアップを取ることで、問題が発生した場合に古い設定に戻すことができます。これは、積極的に監視している小さな変更に理想的です。しかし、この設定は、ディスクの故障やより複雑な事例が発生した場合には失敗します。また、リモートの場所への定期的かつ自動化されたバックアップも必要です。

バックアップ自体は自動フェイルオーバーを提供しません。つまり、障害が発生してもデータが失われることはないかもしれません（バックアップが100％最新の状態であると仮定した場合）が、稼働時間には影響を与える可能性があります。これが、冗長性とバックアップがしばしば併用される理由の一つです。

第2部 — ファイルレベルのバックアップ

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

cpコマンドの使い方

理論的には、cpコマンドを使って、クラウドサーバーのようなLinuxマシンをバックアップすることができます。これは、ファイルを一つのローカルの場所から別の場所へコピーします。ローカルコンピュータでは、外部ドライブをマウントして、そこにファイルをコピーすることができます:

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は、クライアント、バックアップ場所、そして実際のバックアップを調整するコンポーネントであるディレクターの別々の概念で設計されています。また、各バックアップタスクを「ジョブ」と呼ばれる単位に構成します。

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

二重性

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

ファイルバックアップにGPG暗号化を使用する明らかな利点は、データが平文で保存されないことです。GPGキーの所有者のみがデータを復号化できます。これにより、データが複数の場所に保存される際に必要な追加のセキュリティ対策を補うための一定のセキュリティレベルが提供されます。

GPGを定期的に使用しない人には明らかでないかもしれない別の利点は、各取引が完全に正確であることを確認する必要があることです。GPGはRsyncのように、データ転送中にデータの損失がないことを確保するためにハッシュチェックを強制します。これは、バックアップからデータを復元する際にファイルの破損に遭遇する可能性が大幅に低くなることを意味します。

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

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

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

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 — バックアップのバージョニング

データのバックアップを行う主な動機の一つは、不要な変更や削除が発生した場合にファイルの以前のバージョンを復元できるようにすることです。これまでに挙げられたすべてのバックアップ機構がこれを実現できますが、より詳細なソリューションを実装することも可能です。

例えば、これを手動で行う方法は、nanoで編集する前にファイルのバックアップを作成することです:

cp file1 file1.bak
nano file1

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

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

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

このデザインに内在する多くの問題を解決する代替案は、Gitをバージョン管理システムとして使用することです。Gitは主にプレーンテキスト、通常はソースコードの行ごとのバージョン管理に焦点を当てて開発されましたが、ほぼすべての種類のファイルを追跡するためにGitを使用することができます。詳細を学ぶには、Gitの効果的な使い方をレビューしてください。

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

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

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

システムの一時的なイメージを作成するために、スナップショットを作成することもできます。これはバックアップと似た方法で機能しますが、自動化されていません。特定の状況下では、稼働中のシステムのスナップショットを取得することも可能ですが、ファイルシステムへの書き込み方法によっては、常に推奨されるわけではありません。

デジタルオーシャンのバックアップとスナップショットについては、コンテナとイメージのドキュメントから詳細を学ぶことができます。

GitOps

最後に、特定の状況において、サーバーごとにバックアップを実施することが必ずしも必要でない場合があることを指摘する価値があります。たとえば、GitOpsの原則に従ってデプロイを行っている場合、個々のクラウドサーバーを使い捨てとして扱い、代わりにGitリポジトリのようなリモートデータソースをデータの真実の効果的なソースとして扱うことができます。このような複雑で現代的なデプロイメントは、スケーラビリティが高く、失敗に対してもより耐性がある場合が多いです。しかし、それでもデータストア自体や、これらの使い捨てサーバーが情報を送信する可能性のある中央集権型ログサーバーのバックアップ戦略を実施したいと思うでしょう。デプロイメントのどの側面がバックアップを必要としないか、どの側面が必要であるかを考慮してください。

結論

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