サーバーを移動中です。最後の項目の1つは、svnリポジトリーを移動しています。
さまざまなsvnリポジトリの約10ギガがあります。これらは、次のコマンドを使用して作成されました。
svnadmin create --fs-type fsfs
サーバーA（元の）にはsvn 1.4があり、サーバーB（ターゲット）にはsvn1.6があります。
私の考えではrsync、リポジトリのセット全体を移行するために使用することでした（それらはすべてサーバー上の1つのフォルダーにあります）が、移行されないものがあるかrsync、これを機能させるために特別なスイッチが必要になるのではないかと心配しています。
ほとんどのオンラインチュートリアルでは、たとえばを使用して、一度に1つのリポジトリを移動することについてのみ説明していますが、svnadmin hotcopy約100程度を一緒に移動する必要があります。これはそれについて行く正しい方法ですか？
Subversion の FSFS は、異なる OS 間であっても、コピーと移動を行う上で非常に安定しています。mliebelt はダンプのリロードを介してそれを行うことについては正しいですが、10 GB を移動するには時間がかかります!
そのため、次の手順をお勧めします。
ファイルシステム経由でリポジトリを新しいサーバーにコピーします。
例えば$ scp -r /var/repos/ user@newServer:repos/
1.6 のリポジトリを更新します$ svnadmin upgrade(これはオプションですが、マージ トラッキング、スパース チェックアウトなどの 1.5/1.6 機能を使用する場合は強くお勧めします)。
$ svnadmin verify各リポジトリで を実行して、すべてのリビジョンに問題がないことを確認します (これは、既に実行中のサーバーで実行できます) 。
この手順により、おそらく 10 倍から 100 分の 1 の時間が必要になります。
たとえば、リポジトリをダンプする場合、通常は1 時間あたり約 1 GBかかります(主に HD 速度に依存します)。ダンプ ファイルはリポジトリよりもはるかに大きくなります (SVN 1.4 の場合!)。したがって、より大きなファイルを新しいサーバーに移動し、また、GBあたり約1時間かかるダンプロードがあります。これを、GBit-LAN を使用している場合は通常、ネットワーク接続 (100 mbit で約 10 MB/秒) または HD (約 100 MB/秒) によってのみ制限されるファイルシステムのコピーと比較してください。
svn 1.6 の詳細については、こちらsvnadmin dumpを参照してください。、 、およびその他のオプションだけでなく、およびについても説明します。svnadmin loaddumpload--deltas--incremental
また、そのままコピーして svnadmin アップグレードを行うと時間を節約できますが、リポジトリの状態が最適ではない可能性があることに注意してください。svnadmin ヘルプから:
svnadmin help upgrade
使い方: svnadmin upgrade REPOS_PATH
REPOS_PATH にあるリポジトリを、サポートされている最新のスキーマ バージョンにアップグレードします。
この機能は、コストがかかる可能性のある完全なリポジトリのダンプおよびロード操作を実行することなく、新しい Subversion 機能を利用したいリポジトリ管理者向けに提供されています。そのため、アップグレードでは、リポジトリの整合性を維持しながら、これを達成するために必要な最小限の作業のみが実行されます。 ダンプとその後のロードのように、最適化されたリポジトリの状態を保証するものではありません。
まず第一に、私は Subversion の管理者ではありませんが、Subversion と多くの作業を行っています。私の言葉だけを信用せず、他の情報源もチェックしてください。
過去 5 年間の私の経験は次のとおりです。
dumpとを使用する必要がありloadます。それらはその仕事のためだけに書かれています。dumpさらに、すべてが問題ないことをload確認します。それらを使用することで、すべてが正常に動いたという追加の「保険」を得ることができます。したがって、はい、リポジトリを 1 つずつ移動することをお勧めします。