version-control - コードにどのようなバックアップ戦略を使用していますか?

Question

誰もがソースコード管理を使用してバージョンを管理しており (そうですか?)、これによりある程度のバックアップが提供されます。ただし、ローカルコピーがリポジトリと同期していない場合があります。さらに、一部のサンドボックスタイプのプロジェクトは、まだ SCC に組み込まれていない可能性があります ;-)。

編集: プロジェクトディレクトリに複数のプロジェクトがあります。すべてが現在開発中というわけではありませんが、バグが見つかった場合はいつでも「修正」する必要があるかもしれません。SCC から単一のアクティブなプロジェクトを復元することは、完全に理にかなっているように思えます。私がサポートしている数十のプロジェクトすべてを SCC から復元するのは、バックアップから復元し、必要に応じて SCC から同期するよりも合理的ではないように思えます。

コードを安全に保つために、ソースコード管理以外にどのようなバックアップ戦略を使用していますか?

同様の質問はhttps://stackoverflow.com/questions/38388/organization-wide-backup-strategyで見つけることができますが、もしあなたが組織で働いている場合は、他の人の個人的な戦略を聞くことにもっと興味があります。全体戦略。回答で私の戦略を提供します。

score 31 · Accepted Answer

私の戦略は、常にチェックインし、リポジトリ全体をバックアップすることです。

ソース管理から何かを除外することは決してなく、定期的なバックアップ (毎日の増分、完全な毎週、毎月のローテーション) が行われ、機能していることを確認します。

score 13 · Accepted Answer

一日の終わりに、コードをソース管理にチェックインします。

真夜中頃にMozyが起動し、私のコードをオフサイトでバックアップします。

午前 1 時ごろ、SC ボックスはテープにバックアップされます。

午前 3 時頃にSyncback SE が起動し、コードを外部 HD にバックアップします。

一日中、Live Syncを使用して職場のボックスが自宅のボックスと同期しています

score 6 · Accepted Answer

(リモートサーバーへのソース管理に加えて) 無料版の SyncBack (www.2brightsparks.com) と次のバッチファイルを使用します。

@echo off

echo Stop and start SQL Server
echo -------------------------

net stop "SQL Server (SQLEXPRESS)"
net stop "SQL Server (SQLSERVER2008)"
echo -----------------------------------------------------------
echo Back up running now... please wait.

"C:\Program Files\2BrightSparks\SyncBack\SyncBack.exe" c e-contents f-contents

echo Backing up done. Starting SQL Server...
echo -----------------------------------------------------------

net start "SQL Server (SQLEXPRESS)"
net start "SQL Server (SQLSERVER2008)"

echo -----------------------------------------------------------
echo Back up is done and SQL Server is running now.
echo -----------------------------------------------------------

pause

毎日 2 台の 8 GB フラッシュドライブを使用しています。週末に同じことをしますが、デスクトップの外付けドライブをターゲットにします。

SyncBack は素晴らしいです。

score 6 · Accepted Answer

6

OSXのタイムマシン

于 2008-12-29T19:45:03.730 に答える

score 5 · Accepted Answer

私の意見では、時々 SCC からすべてを再構築することは、とにかく良い習慣です (たとえば、夜間)。そうすることで、重要なファイルをリポジトリに追加するのを忘れていないことを確認できます。いずれにせよ、全体の手順には、最大で数ステップが必要です。

score 3 · Accepted Answer

ディスクドライブが故障した場合に、プロジェクトディレクトリ全体を SCC から再構築する必要はありません。

は？私たちはいつもこのようにしています。実際、クリーンなチェックアウトから新しいビルドを継続的に実行するビルドサーバーがあります。バックアップからの復元が SCC からの復元よりも優れていると思われる場合は、SCC を改善する必要があります。

プロダクションの準備が整っていないすべてのコードについて、SCC に「playground」および「junk」と呼ばれるディレクトリがあります。

score 3 · Accepted Answer

Microsoft SyncToy 2.0を使用して、プロジェクトディレクトリをネットワーク共有上のフォルダーと同期します。さまざまなディレクトリに対して異なる SyncToy スクリプトを実行する個別のスケジュールされたタスクがあります (Visual Studio のバージョンごとに分類されます)。

score 3 · Accepted Answer

最も単純な 5 分間のテスト以外はすべて、バージョン管理 (私の場合は Subversion) を使用します。

Linuxを実行する古いハードウェアと、コミットしているSubversionサーバーを使用しました。次に、毎晩リポジトリをアーカイブし（前回から変更された場合）、変更ログを本文に含むメールでgmailアカウントに添付するcronスクリプトがあります。Gmail の添付ファイルは 20 MB に制限されているため、最もバイナリ集約型のリポジトリを除くすべてのリポジトリは、ファイルを分割してバックアップできます。

Amazon S3 にバックアップを配置するためにこれを作り直す予定ですが、まだ実行できていません。

私見で最も重要なことは、USBドライブなどだけでなく、常にどこか（地理的に）にバックアップをとることです。

極小5分の場合テスト私はそれらを DropBox (www.getdropbox.com) に入れました。

score 2 · Accepted Answer

バージョン管理（SVN）で十分です。ただし、いくつかのルールがあります。

私はできるだけ頻繁にコミットします（コミットせずに4〜6時間の作業を行うと、何かがうまくいかないというこのうずくような感覚がすでに発生し始めます）。
ソリューションのSVN構造は常にアトミックです。任意のソリューションで「rebuild-copy-package」統合スクリプトを実行できるようにするには、新しいCheckOutが必要です（テストを実行するには、その前にDB接続設定を提供する必要がある場合があります）。
SVNサーバーは信頼性が高く、定期的にバックアップされます。
変更は、アプリケーションを構成するさまざまなソリューション間で（つまり、オープンソース共有ライブラリからそれを利用する内部コードに）コミットを介してのみ伝播されます（統合サーバーがこれを取得し、下流のソリューションで使用できるパッケージを作成します）。
サンドボックスプロジェクト（プロトタイプ）は、常に「YYYY-MM-DDPrototypeName」という名前のSVN（トランクまたはタグの兄弟）のPrototypesフォルダーに保持されます。

score 2 · Accepted Answer

バックアップに双方向同期ツールを使用しない

...まあ、少なくとも自動的にではありません

unison などの同期ツールが2つ (またはそれ以上) の場所を同期しています。したがって、ある場所で誤ってファイルを台無しにしても、その混乱は別の場所に変換され、気付かないでしょう。

score 2 · Accepted Answer

これは主観的な回答ですが、ソース管理を適切に使用していないと思います。

はい、ローカルコピーはリポジトリと同期していないことがよくあります。頻繁にコミットしている場合、ドライブの損失 (盗難/障害など) の場合、少量 (通常は 1 日未満) の作業が失われます。

他の開発者を混乱させるような、まったくおかしなことをしている場合は、ブランチで作業する必要があります。完了したら、変更を元にマージします。

また、いつでも SCC システムからプロジェクトを再構築できる必要があります。ビルドに必要なものがすべて SCC にあることを確認するためだけに、ときどき行うのは良いことです。過去 6 か月間。

score 2 · Accepted Answer

バージョン管理システムとしてMercurialを使用しています。Windowsラップトップのリポジトリをメインのリポジトリとして使用していますが、Mercurialのクローン機能を使用して、2、3日ごとにubuntuサーバーにバックアップしています. また、sync toyを使用して、ラップトップにあるリポジトリのコピーを含む重要なディレクトリをフラッシュドライブにバックアップしています。

score 2 · Accepted Answer

Unisonを使用して、自宅の 2 つの異なるマシンにホームディレクトリ全体を複製しています。このようにして、私がずさんな場合、またはソース管理下にない 20 年前のファイル ( .emacs) がある場合でも、ある程度の保護を行うことができます。また、個人用ファイル (写真、音楽) 以外のすべてを、職場のマシンにも複製しています。

score 1 · Accepted Answer

私は「TransactorCodeAgent」と呼ばれる製品に取り組んでいます。これは、あなたが求めていることを実行するように設計されています。

ソースファイルのローカルバックアップとバージョン管理を提供します。

これにより、既存のソース管理セットアップを目的に使用して（複数のリリースで複数の開発者による「ほぼ完了した」作業を管理）、進行中の作業に自動バックアップとローカルファイルバージョン管理を提供できます。

ベータ版は1月中にリリースされる予定です。

あなたは私たちの「ウェブサイト」（それは少しラフです）を見ることができます

www.transactor.com

プライベートベータにサインアップするために使用できるフォームがあります。

アップデート：

コメントで得たフィードバックに基づいて、もう少し情報があります。

1）ソース管理に反対するものはありますか？

いいえ！ソース管理は素晴らしいことだと思います。適切に使用すると、ソフトウェアのライフサイクルを管理するための優れたツールを提供します。

ただし、適切に使用すると、ソース管理には大きなギャップが残り、終了するまで開発者の作業が保護されません。必要なのは、個々のプログラマーの進行中の作業に焦点を当てたものです。コードエージェントはそれを行います。

別の言い方をすれば、ソース管理は上司の生活を楽にするために設計されたツールです（時間の経過とともに機能や変更、チームやバージョンを管理するのに役立つため）

コードエージェントは、あなたの生活を楽にするために設計されたツールです（それはあなたの仕事が常に保存されることを確実にするからです）。

score 1 · Accepted Answer

私はTransactorCodeAgentと呼ばれる製品（私が書いた、それは私のmicro-isvです）を使用しています。プログラマー向けに特別に設計されたバックアップツールです。

ソースコードを監視し、変更を保存するたびにバックアップし、ローカル履歴を保持します。

いくつかの理由から、ソース管理よりもバックアップの方がはるかにうまく機能すると思います。

ソース管理は、プログラムをある一貫した状態から別の状態に移行するのに役立つ変更管理ツールとなることを目的としています。
プライベートブランチを維持することを心配する必要はありません
純粋にバックアップ目的でチェックを行うために作業を中断する必要はありません。コードの記述に集中し、完了したらチェックインすることができます。

ここからデモをダウンロードできます。

http://www.transactor.com/download

score 1 · Accepted Answer

VCS にチェックインされていない (したがってバックアップされていない) コードは存在しません。それは、頭の中にあるコードよりも現実的ではありません。それは本当に簡単です。

score 1 · Accepted Answer

また、すべてをチェックイン (早期かつ頻繁にチェックイン) し、リポジトリ全体 (CVS) を tar でバックアップし、バックアップサーバーに ftp します。

score 1 · Accepted Answer

メインビルドに (まだ) 属していないものを作成する場合は、ブランチを作成します。メインビルドに移動する必要がある場合は、ブランチをマージします。

分散型 VCS は、ローカルブランチも非常に簡単にします。中央リポジトリはそれらが存在することを決して知りません。

変更をリモートコピーにプッシュして (分散型 VCS の) ローカルリポジトリをバックアップすることは非常に簡単なので、ほとんどのドキュメント、構成ファイル、基本的にはバイナリ以外のすべてのバックアップの主な方法として git を使用しています。

score 1 · Accepted Answer

ソース管理からかなりの時間離れている場合は、分散ソース管理が必要です。

score 0 · Accepted Answer

MozyProを使用して、マシン上の現在のコードとソースコード管理データベースのオフサイトバックアップを自動化します。これは毎晩段階的に実行されます。

score 0 · Accepted Answer

私は rdiff-backup を使用して、SSH 経由でラップトップの毎日の増分バックアップを実行しています。デルタ圧縮 (rsync など) を使用するため、非常に高速です。また、バックアップされたデータを何日でもさかのぼることができるので、複雑なコードを完成させた直後に戻ることができますが、誤ってすべてを削除する前に戻ることができます.

始めるのは少し難しいですが、私の意見ではそれだけの価値があります。

score 0 · Accepted Answer

Subversion とは別に、私はオンラインオフサイトバックアップにcrashplanを使用しています。また、ローカルストレージや他のコンピューターにバックアップすることもできます (ただし、残念ながら、現在のところ、同じバックアップセットを各宛先に保存する必要があるようです。つまり、重要なものの小さなセットをオフサイトに保存し、より大きなセットをローカルに保存することはできません)。

また、ユニゾン (大きすぎてオフサイトにバックアップできないもの - 音楽、映画など) と OSX タイムカプセルも使用しているため、データが失われた場合でも、オンラインバックアップに頼らずに復元できることを願っています。オンラインバックアップは、家が全焼したり強盗に遭ったりするような災害に備えたものです。

score 0 · Accepted Answer

何かが失敗した場合に備えて、自分が取り組んでいる重要な部分を yahoo や hotmail などの Web メールアカウントに電子メールで送信することがあります。誰もが紙からデジタルへの切り替えについて話していることは知っていますが、何が起こるか分からない場合もあるので、ハードコピーを印刷します。明らかに、これは特に大規模なプロジェクトでは最善の解決策ではないため、通常はハードコピーをより小さく、より重要な部分に制限します。私も少し偏執的になりがちなので、バックアップのバックアップのバックアップを取ることになります。

score 0 · Accepted Answer

オンライン (インターネット) バックアップは、プロセスの重要な部分です。

外部ドライブへのあらゆる種類のバックアップは、任命された個人 (秘書など) によって作成されない限り、失敗する運命にあります。あなたが非常に小規模なショップ (または私のような µ-ISV) の場合、これはオプションではありません。それでも、外付けドライブはどこに保管されていますか? 防火機能付きの金庫が唯一の良い答えです。それらをオフサイトに保管するのは良くありません。定期的なバックアップのためにオフィスに持ち帰るのを忘れてしまうでしょう。

NAS へのバックアップは、外付けドライブよりも優れたソリューションです。しかし、建物が火事になった日、オフサイトのバックアップは生き残る唯一のチャンスです。

私は個人的にMozyを使用して、SCC DB に加えて主要なローカルディレクトリをバックアップしています。

言うまでもなく、他人のハードドライブにソースコードを保存するには、AES-256 または同様の暗号化が必須です。Mozy とそのすべての深刻な競合他社がそれを提供しています。

score 0 · Accepted Answer

joelonsoftware の joel は、いくつかの投稿で、プロジェクトのビルドとデプロイに 2 つ以上のコマンドライン (または準備に 1 分以上) がかかる場合、それは間違っていると述べています。私は彼に完全に同意し、SCM で十分だと思います。バックアップシステムは壊滅的な災害 (HDD の故障、火災、竜巻) にのみ使用されます。

score 0 · Accepted Answer

ただし、ローカルコピーがリポジトリと同期していない場合があります。さらに、一部のサンドボックスタイプのプロジェクトは、まだ SCC に組み込まれていない可能性があります ;-)。

まず、コードが SCC から「外れる」時間を最小限に抑えるように努める必要があります。バックアップ目的ではなく、いつ何が行われたか、特に理由を追跡するためです。コミットコメントは非常に貴重です。「初期リビジョン」というメッセージを含む 3000 個のファイルを含む大きなチェックインはあまり役に立ちません。

サンドボックスプロジェクトの引数にはある程度の重みがありますが、他のすべてのファイルと同じように扱う必要があります。それらを外部USBドライブなどにバックアップします。他のすべてのファイルをバックアップしていない場合は、今すぐ開始することをお勧めします。

そしてもちろん、ディスクドライブが故障した場合にプロジェクトディレクトリ全体を SCC から再構築する必要はありません。実際のバックアップから復元する方がはるかに優れています。

これだけじゃないsvn checkout？「SCCから再構築」しないのはなぜですか？

score 0 · Accepted Answer

私は TFS (Team Foundation Server) を使用しているので、使用している他のデータベースと同じように SQL Server データベースをバックアップするだけです。

score 0 · Accepted Answer

Subversion: サーバーは Beanstalk によって管理され、クライアントは Tortoise SVN を使用します。すべてのコーディングセッションの後、すべてが SVN リポジトリに戻されるため、コードを失う心配はありません。また、定期的に最新のコードを CD にバックアップし、念のためボールトにロックします。

また、コードは方程式の一部にすぎないことに注意してください。最近のほとんどの開発環境では、それ自体で大幅なカスタマイズが必要です (サードパーティツールの統合は明らかな例ですが、適切なオプションを使用して IDE をインストールするだけでもかなりの時間がかかります)。したがって、私はすべての開発を、外付けハードドライブに簡単にバックアップできる仮想マシンで行っています。これらもボールトにロックされます。

最後に、「参照」データベースをバックアップして全体像を完成させます。私の製品では、重要なシステムデータがデータベースに保持されているため (たとえば、Web サイトで配信されるコンテンツ)、スキーマをバックアップすることはできません。

version-control - コードにどのようなバックアップ戦略を使用していますか?

28 に答える 28

Related

Reference