問題タブ [backup-strategies]

公開鍵で暗号化されたファイルの自動バックアップ場所を作成して、私だけがファイルを開くことができるようにする予定です。家庭用ハードウェアを扱いたくありませんが、通常のホスティングは数 GB または TB には高すぎます。

最も難しい問題は、どこに保存するかです。GB あたりのコストが非常に安いため、Google ニアライン ストレージを場所として使用できますか? または、そのような個人的な使用に制限はありますか?

または、それほど多くのコーディングをせずに、より優れた/より簡単なソリューションがいくつかありますか?

私の目的は、S3 との間で dynamodb テーブルをバックアップおよび復元することです。データ パイプラインと DynamoDb ストリームを使用したインポート/エクスポートについて認識しています。Data Pipeline を使用する際の私の懸念は、バックアップ プロセスが完了したときに、バックアップが実行された「ポイント イン タイム」を確認できないことです。たとえば、バックアップ プロセスが午前 11 時に開始され、午前 11 時 30 分に終了した場合、バックアップ内のアイテムは、午前 11 時から午前 11 時 30 分までに dynamodb テーブルで発生したすべてのものである可能性があります。

DynamoDb ストリームを使用してデータ パイプラインを補完するにはどうすればよいですか?

dynamodb テーブルを特定の「特定の時点」に復元するにはどうすればよいですか?

RHEL で実行されている MonetDB データベースが数億行 (数百 GB) の範囲にあり、数十 (数百ではない) のテーブルがあり、適切なバックアップ戦略を実装することに興味がある場合、特にそうするメカニズムに。

これまで、私は bash スクリプトを使用して、データベース内のテーブルごとに 1 回ずつ msqldump を繰り返し呼び出し、次のようなファイルにデータをパイプしてきました。

.monetdb ファイルをセットアップしたので、msqldump を呼び出すたびにパスワードの入力を求められることはありません。そのため、このスクリプトを呼び出して無人で完了することができます。

これらのテーブルを MonetDB データベースに復元するために必要なすべてのデータとスキーマを含む一連のファイルを取得する限り、これは機能しているように見えますが、どちらも非常に粗い (そして実行に時間がかかる) ように見えるので、私は「より良い」方法があるのだろうか？

たとえば、msqldump 操作中にデータベースの内容が変更された場合、どうなるか心配する必要がありますか? おそらく db/farm を停止し、データ ファイル自体のコピーを取得するだけで、MonetDB データベースの完全なバックアップを取得するクリーンで高速な方法はありますか? もしそうなら、これを達成するための正確な方法は何ですか? MonetDB を何らかの大規模またはエンタープライズな方法で使用している人々/組織はありますか? また、MSSQL データベースまたは同様のものに実装される可能性のある同じ種類のバックアップ戦略をどのように達成していますか?

私はオンラインでかなり多くのことを検索しましたが、ここでは StackOverflow で、この主題に関するガイダンスの方法で多くを見つけることができなかったので、ここの誰かが助けてくれることを願っています.

前もって感謝します。

ファイルを同じようにコピーするバックアップルーチンを設定しようとしています。Mac Automator ルーチンで Rsync をセットアップして、MacBook に接続された Windows フォーマットのリムーバブル ドライブを Wi-Fi ネットワーク上の NAS ドライブに同期させました。

「rsync -va」を使用しています。ソースは 37GB です。ルーチンを約 12 時間実行したままにしました。宛先フォルダを確認すると、サイズが 80GB を超えていたため、この時点でルーチンを停止しました。

「rsync -avnc」を実行してフォルダーが同じかどうかを確認すると、ソースの内容の完全なリストが表示されます。これは、宛先のファイルが同じではないことを意味していると思いますか?

Automator を使用して必要なことを簡単に実行できるように、ルーチンを完成させようとしているので、宛先フォルダーを削除してやり直します - 正確なコピーを取得するには、Rsync で何を変更する必要がありますか?

私はブランチを WIP のバックアップとして使用しています。git diffしかし、戻ってきて、自分の仕事を続けながら変更をもう一度概観できるように、背中を向けたいと思っています。

そのため、通常はWIP コミット( ) をリセットして、git reset HEAD^作業を再開します。しかし、再度コミットする必要があり (決定的なコミットまたはWIP コミット)、それをリモートのオリジンにプッシュする必要がある場合、この新しい分岐コミットが同じブランチをプルする共同作業者に問題を引き起こす可能性があるのではないかと思います。

彼らが変更を加えてコミットするなら、彼らがそうするだろうと私は知っています。しかし、彼らがブランチを引っ張っただけで、それに触れることはなく、その結果、2 つ目の新しい分岐 WIP コミットを引っ張った場合はどうなるでしょうか?

協力者のブランチに触れないことに同意するだけで十分安全ですか?

短い形式での質問:フォローアップから、質問の核心を強調して単純化する必要があるようです。核心は次のとおりです。Android DB の他のバックアップ オプションでは、現在データベースにあるデータが復元によって上書きされる可能性があるというリスクが残っているようです。これはそうですか、このリスクなしでバックアップ/復元する方法はありますか?

.

長い形式の質問: Android で SQLite データベースをバックアップすることに関する多くの (かなり多数の) 質問に目を通しましたが、答えが見つからない質問が 1 つあります。

他のすべてのバックアップ/復元の説明では、db ファイルを SD に保存し (または、Android で SQLite データベースを Dropbox にバックアップ/復元する方法でクラウドに)、必要に応じて復元することについて説明しました。私の懸念は、復元によって現在の DB が上書きされないかということです。

ユーザーが短時間使用していたアプリを新しくインストールし (新しいデータを生成)、アプリの以前のバックアップからデータをインポートしたい場合が心配です。他のすべてのバックアップ/復元アプローチでは、古い DB ファイルを復元すると、現在の DB ファイル内の新しいデータが上書きされるようです。代わりに欲しいのは、復元時にバックアップから現在のDBにデータを追加して、その中の他のものを上書きせずに完全にするバックアップオプションです。

他のアプローチはこれを行いますか？それとも、私が疑うように、そのような場合に上書きしますか?

彼らが上書きする場合、私の最善のバックアップオプションはおそらくcsvまたはxmlファイルなどに書き出すことであり、これらのバックアップの議論はそれを行う簡単な方法についてのものであると思っていました. そのプロセスを高速化して簡単にするために構築されたプロセスはありますか、それともすべて手動で行う必要がありますか? もしそうなら、書き込むフォーマットに関する推奨事項とその理由は?

同様に、BackupAgentHelper を使用した組み込みの Google バックアップで同じ上書きの問題が発生するかどうかを知っている人はいますか?

最後に、データ移行 (コア データ モデルが変更された後にバックアップから SQLite データベースを復元する方法 (軽量移行) に似ています) を経てしまった場合、今何をすべきか (私はまだ DB 設計段階にあります) ) このような将来の変更を、このバックアップ プロセスと比べて容易にする方法はありますか?

私は初心者ですが、ソースのフォルダーの内容を読み取り、ファイルを宛先と比較し、一致をバックアップしてから、ソース ファイルを宛先に移動するバッチ ファイルを作成しようとしています。ソースディレクトリのファイルの内容がマスクとして機能していると思います。

この結果を得るために使用できる手法はありますか? 私は試してみましRobocopyたXCopyが、私が探しているものではありません。XCopy除外オプションがありますが、それは私が必要とするものとは逆です。どんな提案でも大歓迎です。

セットアップは次のようになります。

これらのフォルダにはこれが含まれています

古いファイルを置き換える新しいファイルがあります。

ソース ファイルが宛先ファイルを上書きする前に、すぐに上書きされるファイルのみをバックアップする必要があります。

if ステートメントを試しましたが、その後の行方がわかりません

これで、私がやろうとしていることの一部が明確になることを願っています。

次の手順を実行しました。

1. nuget パッケージとビジュアル スタジオを使用して、新しい Umbraco インスタンスを作成しました。
2. Azure DB をバックエンドとして使用して、Azure にデプロイしました。
3. articulate パッケージをインストールしました。
4. プロジェクトをバージョン管理に追加しました (App_Plugins フォルダー、明確な dll などを含む)。
5. umbraco のインストールを削除でき、Articulate を含むバージョン管理から完全に復元できます。

現在、コンテンツ、記事、写真などを追加し始めています。

Web サーバー上のフォルダー全体をバックアップする必要はないと思います。Azure DB の定期的なバックアップを行っており、次のような新しいコンテンツで満たされたいくつかのフォルダーが必要です。

• メディア (記事に追加する写真でいっぱい)
• App_Plugins (インストール済みパッケージを umbraco に保持)
• App_Data/packages (インストール済みパッケージのファイル ディレクトリ)
• App_Data/umbraco.config (Articulate の一部のコンテンツを保持)

では、バージョン管理部分、azure db バックアップ、およびリストされたフォルダーを使用して、システム全体を復元できるようにするために必要なのはこれだけですか?

私たちは 2 つのサイトを持つことを決定できる立場にあるので、メイン システム(サイト 1 -- 当社のビジネスの主要な場所)がダウンした場合、いくつかの仮想マシン、ファイル サーバー/ファイル共有、SQL および Exchange を他のシステムでスタンバイ状態にします。サイト(site2 -- セカンダリ ロケーション) . そのため、何らかのバックアップがあるため、会社全体を非常に迅速に稼働させることができます。

皆さんにお聞きしたいのは、「ライブ バックアップ」サーバー/ファイル共有についてです。

Windows Server にはいくつかのツールがあり、サイト 2 にまったく同じファイル共有のコピーを作成できますか? フェールオーバー クラスターか何かのように？site1 と site2 のファイル共有が通信し、なんらかの連絡先が必要になるため、ユーザーがいくつかの写真をプライマリ ファイル共有 ( //fileshare1 ) にコピーすると、セカンダリ ファイル共有 ( //fileshare2 ) またはServerが存在したことになります。プライマリ サーバー/ファイル共有にいくつかの変更が加えられ、その画像が site2 にコピーされます。ある種の「ライブ バックアップ」またはミラーリング。

Windows Server にはこのようなオプションがありますか?

ご助力いただきありがとうございます！