EC2サーバーのオフサイトバックアップの方法は？
AmazonVPC上で12個ほどのUbuntuLinuxWebサーバー実稼働インスタンスを実行します。インスタンスはブートストラップされ、Puppetを介して管理されます。ほとんどの管理はAWSコンソールを介して行われます。
AWSの認証情報はかなり安全です。マスターアカウントはほとんど必要なく、強力なパスワードと2要素認証を備えています。信頼できる管理者の中には、強力なパスワードと2要素認証を使用して、自分のIAMアカウントを介してほとんどのサービスにアクセスできる人もいます。一部のIAMアカウントでは、S3へのファイルの書き込みなど、特定の目的のためにアクセスが非常に制限されています。他の従業員による高レベルの資格情報へのアクセスは非常に制限されています。全体として、誰かがコンソールまたはAPIにアクセスする可能性は低いようです。
最近の コードスペースの大失敗 、誰かがAWSコンソールへの高レベルのアクセスを取得し、インスタンス、ボリュームおよびEBSスナップショットを削除しました、Code Spacesがビジネスを回復することを事実上不可能にしているため、データをオフライン/オフサイトでバックアップする方法を調査するようになりました（つまり、メインのAWSアカウントの範囲外）。
AWSの認証情報にアクセスした人や、AWSでの災害によって、顧客データが消去されないようにするにはどうすればよいですか？自動、安定、リーズナブルな価格。
数時間検索した後、「簡単な」方法を見つけることができないようです。 EBSスナップショットを別のAWSアカウントにコピーすることは不可能のようです。 EBSスナップショットをS3オブジェクトにエクスポートできません。サードパーティのサーバーからプルすることですべての重要なデータをrsyncできますが、サーバーの数の変化、保持、エラー処理などを処理するためにスクリプトを作成する必要があります。多くの作業のようです。このためのすぐに使えるソフトウェアは見つかりませんでした。
現在のバックアップ戦略は、すべてのボリュームの夜間に自動化されたEBSスナップショットと、圧縮されたMySQLダンプをS3にアップロードすることで構成されています。すべてのソースコードとPuppetコードは外部バージョン管理からデプロイされますが、お客様のファイルとMySQLデータベースは、EBSボリュームとそのスナップショット、つまりAWSエコシステムの内部にのみ保存されます。
多くの人がこれを考えすぎる傾向があります。これらのサーバーは、コロまたは企業のデータセンターに導入されているかのように考えてください。その場合、どのようにバックアップしますか？
おそらく、テープライブラリまたはVTLに接続されている「レガシー」バックアップ製品（Netbackup、Amanda、BareOSなど）を経由するでしょう。
これは、AWSインフラストラクチャに対して行うことを検討する必要があることです。バックアップサーバーとテープライブラリを構築するAmazonの外部どこかで、それを「最悪の日」の復元方法として使用します。
テープは最も信頼性の高いデータストレージメカニズムの1つであり、他のすべてのクラウドバックアップシステムとは異なり、CodeSpacesで発生したタイプの問題に対して脆弱ではありません。バックアップデータは本当にオフラインであり、オフィスの防火金庫からレンタルまで、テープを好きな場所に安全に保管できます。地元の銀行の貸金庫。クラウドストレージプロバイダーからそのような保護を取得することは不可能です。
構成管理はすでに実施されています。 （そうです！）したがって、災害が発生した場合、サーバーを適度に高速に再構築できるため、テープバックアップ（またはVTL）は主にdata 。データベース、アップロードされたファイルなど。パペットマニフェストでカバーされていないもの。
これがオプションでない場合、次善の策は、バックアップの目的で完全に別個の AWSアカウントを作成することです。そのアカウント内で、アップロード専用のアクセス許可を持つS3のIAM認証情報を作成し、それを本番環境からプッシュバックアップに使用します。これらの資格情報が本番の資格情報とは完全に別の場所に保持されていることを確認して、両方が同時に侵害される可能性を制限します。