私の個人的なものでは、svnadmin hotcopyコマンドを週に1回使用しますが、多くの開発者を含むよりミッションクリティカルなリポジトリでは、それで十分ですか？または、完全バックアップと増分バックアップを含む、より厳密なバックアップ戦略をまとめるために時間を費やす必要がありますか？
hotcopy最も簡単な方法のようですが、何らかの理由でレポが破損した場合にレポを復元できるようにしたいと思います。を介してダンプを実行するだけで、hotcopyこれを実行できますか？
12102 次
6 に答える
13
ホットコピーが心配ですか、それとも 1 週間に 1 回だけバックアップするのが心配ですか?
Hotcopy は、他のプロセス (開発者など) が同時にリポジトリにアクセスした場合でも、リポジトリの安全で完全なバックアップを作成します。それでも信頼できない場合は、リポジトリへのすべてのアクセスをシャットダウンし、通常のファイル システム ツールを使用してどこかにコピーしてバックアップします。(開発者は 24 時間体制で作業するつもりはありませんよね?)
週に 1 回の部分が心配な場合: 次のバックアップが予定されている前日にレポが消えたらどうなるか考えてみてください。それは問題ですか？はいの場合は、より頻繁にバックアップを作成してください。それはとても簡単です。
リポジトリが大きすぎて、数日または数週間分の完全バックアップを保持できませんか? 完全バックアップと増分バックアップを使用するローテーション バックアップ スキームを実装します。バックアップ用の十分なスペースがありますか? 手間を省いて、完全なバックアップを作成してください。
于 2008-11-21T20:34:39.003 に答える
8
もう 1 つの優れた戦略は、2 つ目の SVN リポジトリを保持し、それをsvnsyncを使用してメインのリポジトリと同期することです。通常はポストコミット フックを使用します。
主な利点は、最初のリポジトリが何らかの理由でダウンした場合、すぐにバックアップのリポジトリに切り替えて、ダウンタイムなしで作業を続けることができることです。
于 2008-11-21T17:18:45.233 に答える
2
pythonスクリプトを使用して、企業の SVN 1.4.x リポジトリ (当時は Windows でホストされていた) のバックアップ計画を実装しました。svn-backup-dumps.py
svn-backup-dump.pyフックから呼び出しpost-commitて、特定のリビジョンの増分バックアップをトリガーします。以前schtasksは、同じスクリプトを使用して毎週の「完全」バックアップをスケジュールしていました。
復元 (リポジトリ内のディレクトリを指で削除したために 2 回実行する必要がありました) は比較的単純です。最新の完全バックアップを取得して復元します。最後のリビジョンまで増分を適用します。
この分野での 1.5 の改善/変更については調べていませんが、同様の計画がうまくいくと思います。
于 2008-11-21T16:58:16.537 に答える
2
古い学校と呼んでください。しかし、パーティションへのサブバージョン管理と、スケジュールによるゴースト化についてはどうでしょうか?
Davide Gualano によって提案された svnsync オプションも良さそうです。ドライブの不必要なパーティション分割を防ぐために、このオプションに傾いています (これは、他の管理者を間違った方法でこする可能性があり、一部の VPS 環境では意味がありません)。
添加
最近、svnadmin 'dump' コマンドを頻繁に使用しています。これは、リポジトリを bak create コマンドにエクスポートするという点で、mysql の dump コマンドとよく似ています。このコマンドは、crontab / スケジュールされたタスクとして実装し、ファイルとして外部ドライブにコピーできます。コマンド例:
svnadmin dump c:\svn\project > c:\dumps\project.bak
svnadmin load c:\svn\project < c:\dumps\project.bak
次に、robocopy / 選択したコピー ツールを使用して、ファイルを別の場所に移動します。これは、リポジトリ サーバーからファイルを完全に移動したいが、subverion への外部アクセスがない場合に便利です。
私はまだこれを芸術に落とし込んでいません。これらのファイルをマシン間で移動すると、ときどき「UUID の不一致」のようなメッセージが表示されます。プロジェクトフォルダーを削除/アンダースコアリングしてから、次を使用してこれを解決しています。
svnadmin create c:\svn\project
svnadmin load c:\svn\project < c:\dumps\project.bak
これでエラーが解消されるはずです。Eclipse または他のプロジェクトとのリンクを再作成または復元する必要がある場合があります。UUID が壊れていると、プロジェクトを使用している他の人にも影響を与える可能性があるため、これは考慮する必要があります。
この方法は、ホットコピーのフォールバックとして使用できます。それらの間で、レポを復元できるはずです。
PS ケン、svn-backup-dumps.py がここに移動されたようです: http://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svn-backup-dumps.py
于 2009-11-03T12:45:06.110 に答える
1
以前に破損していないバックアップの上に破損したレポをホットコピーすると、破損していないバックアップが失われます。
これが心配な場合は、他の人が言っているように、バックアップをローテーションする必要があります。
'svnadmin verify' を自動的に実行するように手配することもできます。
于 2008-11-24T19:23:40.250 に答える
-1
私は過去にホットコピーだけで不運に見舞われました。1 日に何度も更新およびコミットされるコードの場合は、より詳細なバックアップ戦略を検討する価値があるかもしれません。
于 2008-11-21T16:29:12.647 に答える