Apache Subversion (SVN) を汎用バックアップ ツールとして使用することはできますか? (一種のrsync代替手段として。)
12 に答える
この記事は、svn を使用してホーム ディレクトリをバックアップする方法などについて非常に優れた説明であることがわかりました。
Linux ボックスのバックアップには Subversion を使用しています。ちょっとした工夫で、次のことを簡単にカバーできます。
- 毎日のスナップショットとオフサイト バックアップ。
- ファイルやフォルダの追加・削除も簡単。
- ファイル バージョンの詳細な追跡。
また、いくつかのボーナス機能も利用できます。
- Subversion のイベント フックを介してファイル システムのアクティビティを追跡するための定期的なログ メール。
- ユーザーは、任意のリポジトリ リビジョンからホーム フォルダのチェックアウトを要求できます。
- 新しいサーバーまたは交換用のサーバーは、いくつかの svn checkout コマンドでセットアップできます。
ソース: http://www.mythago.net/svn_for_backup.html
ホームディレクトリのバージョン管理の例を示すこの記事も見つけました。これにより、ホーム ディレクトリを新しいマシンにチェックアウトすることで、環境を持ち運ぶことができます。私は似たようなことをしたことがあり、非常に便利であることがわかりました。
「汎用」バックアップとしては、主に他の人から与えられた理由 (多くの余分なフォルダーと無駄なディスク容量) から、おそらく最高のアイデアではないと思います。バックアップを保持したいだけの場合は、ニーズに応じて、おそらくより良いオプションがあると思います。たとえば、すべてのファイルのすべてのバージョンを保持する必要がありますか?それとも、データの特定のスナップショットで十分でしょうか?
しかし、私のオフィスには 6 人の小さなチームがあり、共有ファイル (例: ポリシーと手順のマニュアル、登録フォームなど) を扱っています。多くの場合、チーム メンバーはリモート (自宅または旅行中) で作業し、オフラインで作業することもよくあります。中央の共有フォルダー セットアップを使用するのではなく、SVN を使用して、各ユーザーにフォルダーの作業用コピー全体を提供し、可能な限り作業、参照、同期を行うことができます。これは一石二鳥です。誰もがオフライン中でもファイルにアクセスして編集できます。さらに、バックアップの冗長性が大幅に向上します。ラップトップが発火した場合、別のコピーを(明らかに別のコンピューターで)チェックアウトできるので、面倒ではありません。サーバーが発火した場合、復元するリポジトリのバックアップがあります。サーバーとすべてのリポジトリ バックアップが発火した場合、失われたのは古いバージョンのファイルだけです。現在のデータを失う唯一の方法は、サーバー、リポジトリのバックアップ、およびチェックアウトを備えたすべてのコンピューターが不思議なことに発火した場合です。
ただし、一部の人が言っているように、SVN はリポジトリから情報を削除することはありません。つまり、バックアップを 60 日間だけ保持したい場合は、それはできません。これは正確には正しくありません。export、dump、およびimportを使用すると、古いバージョンのファイルを効果的に消去できます。きれいではありませんが、可能です。
バイナリ ファイルのバックアップとして SVN を使用する場合、SVN は各ファイルのローカル コピー (.svn/text-base ファイル内) を保持するため、ファイルのサイズが 2 倍になることに注意してください。
それとは別に、バックアップにもSVNを使用しています。すべてのファイルを追加してから、スクリプトを介してコミットするだけです。
私はSVNを使用してコンピューターをバックアップし、ラップトップとデスクトップを同期します。ただし、以前の回答で述べた問題、主にディスク使用量の2倍があります。また、過剰なファイルとSVNプロセスがHDの変更を常にチェックしているため、マシンの速度が低下していると感じています。
ただし、SVNはさまざまなマシンを同期するのに最適であり、必要に応じてどこからでもファイルをチェックアウトできるというボーナスもあります。ブラウザーでWebインターフェイスを介してチェックアウトすることもできます。時折。
要約すると、私は汎用バックアップにSVNを使用することについて複雑な気持ちを持っています。ただし、そうする場合は、映画、写真、音楽などのライブラリを保存しないことをお勧めします。これらのライブラリは大きく(スペース使用量が2倍になるために非常に苦労する)、不変である傾向があるためです。そのためのバージョン管理システムは必要ありません。まれに、ファイルを変更する場合、通常は古いバージョンは必要ありません(SVNは、バイナリファイルの差分の作成/保存が得意ではないため、ファイルの新しいバージョン全体を保存します)。したがって、SVNをこれらのケースに適合させることができない限り(私の長年のプロジェクト意図)、これらの種類のファイルをバックアップするための代替方法を使用することをお勧めします。
また、 bup - git packfile 形式に基づく非常に効率的なファイル バックアップ システムを検討することもできます。データを保存する方法はgitに基づいており、ファイルとその違いを保存するのに非常に効率的です。
Linux で SVN をバックアップとして使用するには、次の手順を実行します。
- 空のレポを作成します。
- 空のリポジトリを、バックアップするフォルダ ツリーにチェックアウトします。
- 次のコード スニペット (svnauto) を使用します。「myuser」と「mypassword」をリポジトリの有効な資格情報に置き換える必要があります。
#!/ビン/sh svn status --depth=infinity --username=myuser --password=mypassword > /tmp/svnauto_tmp.list 猫 /tmp/svnauto_tmp.list | grep '^?' | | sed -e の/^? /svn add --depth=infinity --force --username=myuser --password=mypassword "/g' -e 's/$/@"/g' | し 猫 /tmp/svnauto_tmp.list | grep '^!' | | sed -e の/^! /svn delete --username=myuser --password=mypassword "/g' -e 's/$/@"/g' | し rm -f /tmp/svnauto_tmp.list svn 更新 . --username=myuser --password=mypassword svn commit --username=myuser --password=mypassword --message "自動バックアップ"
上記のスクリプトは、現在のディレクトリ内のファイルとサブディレクトリを追加/削除および更新します。cd
バックアップしたいフォルダ(もちろん作業コピーである必要があります)に単純に使用するには、 svnauto
. システムに grep と sed をインストールする必要があり、/tmp に一時ファイルが作成されることに注意してください。次のcronスクリプトを使用して、夜間コミットのcronジョブから使用できます。
#!/bin/sh
export LANG=en_US.UTF-8 && cd /my/directory && echo Starting backup $(date) > /root/backup_log.txt && /root/svnauto >> /root/backup_log.txt 2>&1 && echo Finished backup. >> /root/backup_log.txt && cat /root/backup_log.txt
この cron スクリプトは、それがバックアップするフォルダーであると想定して/my/directory
います (必要に応じて置き換えてください)。svnauto
また、スクリプトを に配置することも前提としています/root
。ログを作成し、最後に表示します。もう 1 つの詳細: export
svn が適切な言語を見つけるために最初の情報が必要です。機能させるには、この行を自分のローカル言語に調整する必要がある場合があります。
svnが追跡するすべてのフォルダーに入れる「.svn」フォルダーです。
フォルダーをコピーするときは、それらをコピーしないように注意する必要があります (そうしないと、サンドボックスがイライラする可能性があります)。 svn リソース フォルダー。
ソース管理を使用して環境を制御するというアイデアが気に入っています。しかし、私は個人的にこの仕事にsvnを選びません。私はgitのようなものに行きます。しかし、それはおそらく私だけです...
バックアップにSVNを使用すると機能します。ただし、時間の経過とともに、不要な古いリビジョンを削除することが困難になる可能性があります。30日または60日のバックアップのみを保持したいとします。SVNは、X日より古い履歴を削除する簡単な方法を提供していません。古い履歴を削除する方法がない場合は、最終的にバックアップドライブの容量が不足します。
svndumpfilterコマンドに関するSVNブックからの引用は次のとおりです。
Subversionはすべてを不透明なデータベースシステムに格納するため、手動で微調整を試みることは、それほど難しいことではないにしても、賢明ではありません。また、データがリポジトリに保存されると、Subversionは通常、そのデータを削除する簡単な方法を提供しません。[13]
[13]ちなみに、これは機能であり、バグではありません。
rsyncの代替手段として、 unisonがsvnよりも優れたオプションであることがわかりました。
/ etcをソースコード管理でバックアップすることは、システムに影響を与えた変更を元に戻したり、変更を試したり、あるサーバーから別のサーバーに変更を転送したりする場合に非常に役立ちます。
しかし、Subversionの多数の.svnディレクトリは、検索時だけでなく、*。dフォルダーのように、設計が不十分なシステムが.svnフォルダー自体を構成データを含むものとして解釈する場合もあります。
/ etcの下に単一の.hgフォルダーを配置するため、/etcのバックアップにMercurialを使用することを好みます。バージョン管理だけでなく実際のバックアップでは、その.hgフォルダーを別の場所にコピーする必要があります。
JoaoPSF による次のステートメントは正しくありません。
(SVN はバイナリ ファイルの差分を作成/保存するのが苦手で、ファイルの新しいバージョン全体を保存します)
Subversion がバイナリ ファイルを処理する方法からのこの引用を参照してください。
ファイルがバイナリであるかどうかは、そのファイルへの変更を格納するために使用されるリポジトリ スペースの量にも、クライアントとサーバー間のトラフィックの量にも影響しないことに注意してください。保存と送信の目的で、Subversion はバイナリ ファイルとテキスト ファイルで同じように機能する差分メソッドを使用します。これは、svn diff コマンドで使用される差分方法とはまったく関係ありません。
私は Ghost の代用として CVS を使ったことがあるので、その理由がわかりません。
ベースラインにタグを付けることができるので便利です。マシンの管理を変更できます。
これは明らかに、Windows よりも UNIX でうまく機能します。
その考えを思いとどまらせるのは、一般的な使用では、バイナリデータが変更されるたびにコピーされるのに対し、SCM システムのベースとなるテキストコンテンツは差分の形式で簡単に更新できることです。
あなたはそれを行うことができますが、多くの編集を行う場合、写真リポジトリなどを管理するために使用したくない場合があることに注意してください.
より汎用的なバックアップ ソリューション (Time Machine など) の優れた点は、スペースを節約するために、しばらくすると複数のバイナリ変更をロールアップできることです。SVN、git、またはmercurialでそれがどれほど簡単かはわかりません。