rsyncコマンドを使用したSVNバックアップ
SVNリポジトリ（8 GB）を別のサーバーにバックアップするためのcronをセットアップしました。しかし、エラーが発生することがあり、これはsvnをリモートサーバーにバックアップする適切な方法ではないと感じます。
コマンドrsync-avzmyrepoを使用しました。
リモートサーバーへのsvnバックアップを行うための良い方法を教えてください。 7 GBなので、ファイルを圧縮して毎日転送することはできません。
ありがとう
要約：rsyncは、svnリポジトリをバックアップするのに完全に問題ないはずです現在アクティブなリポジトリをバックアップします。問題のあるアクティブなリポジトリをバックアップしようとしていると思われます。
詳細：
どのエラーが報告されているかは言わないため、診断を試みるのは困難です。これは私が定期的にユーザーについてうめき声を上げているものです-アプリケーションが特定のメッセージを提供する場合診断/サポートを求めている人にその特定のメッセージを報告するメッセージは実際には「エラーが発生しました」または同様のものです（これが発生するため）。
報告されている問題は、ファイルが見つからない（最初のスキャン中に存在したが、バックアップが完了する前に移動/名前変更/削除された）、ロックされている、またはrsyncがファイルを読み取っている間に明らかに変更されたことに関連していると推測しています。ライブsvnサービスをバックアップし、バックアップの実行を開始する前にsvnサービスを完全に停止しない場合、ほとんどのバックアップ手法で同様のエラー（またはさらに悪いことに関連しているが報告されていない問題）が発生します。
バックアップの実行中にリポジトリへのすべてのアクセスを停止することは、たとえそれが真夜中に行われたとしても、オプションではない場合があります（異なる時間に作業するリモート開発者がいる可能性があるため）。この場合、次のようないくつかのオプションがあります。
hot-backup.pyを使用して、リポジトリの稼働中にリポジトリの完全バックアップを実行します このセクションで説明 無料で利用可能な Subversionを使用したバージョン管理 これは一般的に推奨されると考えられています読書。これは、毎回完全なリポジトリが回線を介して送信されるため、リモートバックアップには直接適していませんが、一時的なローカルエリアにバックアップを実行して、rsync（またはその他の何か）を実行できます。 ）ライブリポジトリではなく、それに基づくバックアップ。Linuxで実行していて、ドライブのパーティショニングにLVMを使用している場合は、LVMのスナップショット機能を使用して、オプション1で説明したのと同様の機能を実行できます。たとえば、 ここ および ここ を参照してください。テクニックのドキュメント。これは、スナップショットの作成にかかる時間の間、SNVサービスへのアクセスを短時間停止することを意味しますが、これはほぼ瞬時に発生する可能性が非常に低いため、バックアップ操作全体で停止する必要があります。 。
上記のSVNブックにも記載されている、ライブリポジトリの増分バックアップを使用します。
LVM手法は、hot-backup.py- then-syncよりも高速ですが、LVMを既に使用していて精通していない限り、追加の作業と学習のチャンクなしでは利用できません。その利点は、ほぼ確実に大幅に高速になり、使用するディスク容量が少なくなることです（ただし、最近のディスク容量はかなり安価に入手できます）。 LVMスナップショットは、存在している間は書き込みパフォーマンスに影響しますが、リポジトリが非常に非常にビジーであり、パフォーマンスがとにかく通常に戻る場合を除いて、違いが目立つことはほとんどありません。スナップショットをドロップするとバックアップが実行されます。
hot-backup.pyメソッドには、ローカルバックアップがない場合にもローカルバックアップを提供できるという利点があります。「ホットコピー」バージョンを別のマシンに保存すると、復元するよりもはるかに迅速に復元できます。プライマリマシンが他のマシンに影響を与えないイベント（たとえば、ドライブコントローラの障害）で停止した場合のリモートコピー。また、すでにLVMを使用していて、それに精通していない限り、実装が簡単になる可能性があります。
増分バックアップはこれらの両方の手法よりも高速ですが、hotcopy-then-syncよりも単純ではなく、完全災害後の復元は、増分バックアップを使用してもう一方の端で完全リポジトリコピーを作成しない限り、より複雑になる可能性があります。増分情報の保存）。とにかく、もう一方の端でリポジトリを再構築することをお勧めします。これは、バックアップが実際に有効であることをテストする方法であるためです。他の手法を使用しても、バックアップを定期的にテストする必要があります（マントラ：バックアップは、それがない限り、適切なバックアップではありません）。テスト済み）。
要約すると、rsyncはsvnリポジトリをバックアップするのに完全に問題ないはずです（他の多くのテクニックと同じように、私はかなりのファンですrsyncのほとんどのユースケースでは私自身）現在アクティブなリポジトリをバックアップしていない限り-サービスを停止するか、一部のリポジトリからバックアップする必要がありますスナップショットの形式。
同じくsvnを実行している別のサーバーへのsvnsync（svnの一部）はどうですか？トランスポートとして、ssh + svnを使用できます。
ライブのsvnリポジトリを直接コピーすることは決して良い考えではありません。
svnadmin dump --incrementalを調べてフォルダーを調べ、それをrsyncすることができます。このようにすると、増分を転送するだけで済みます。
別の方法はsvnadmin hotcopyで、ライブリポジトリの同一のコピーを作成し、それをrsyncします。
次の場合は、rsyncを使用してアクティブなSVNリポジトリをライブバックアップできます。
- fsfsストレージバックエンドが使用されます
- ファイルを正しい順序でコピーします（db/currentファイルを最初に）
また、現在のトランザクションを確実にコピーできないため、transactions /サブディレクトリの内容をコピーしても意味がありません。
この方法でコピーされたリポジトリは一貫性があり、db/currentファイルがコピーされる前の最後のコミットまでのデータが含まれます。
（ホットバックアップの問題の1つは、最小のバックアップを保持するオプションを使用すると、リポジトリが変更されていなくても、常に新しい番号が付けられるため、すべての夜間バックアップが同期されることです。）