Какую стратегию резервного копирования вы используете для своего кода?

Question

Каждый использует управление исходным кодом для управления версиями (верно?), И это обеспечивает некоторый уровень резервного копирования. Однако бывают случаи, когда ваша локальная копия не синхронизирована с хранилищем. Более того, некоторые проекты типа «песочницы», возможно, еще не сделали ;-) превратили его в SCC.

РЕДАКТИРОВАТЬ : У меня есть несколько проектов в каталогах моих проектов. Не все находятся в текущей разработке, но любой из которых может нуждаться в «исправлении» при обнаружении ошибки. Восстановление одного активного проекта из SCC кажется вполне разумным. Восстановление всех из пары дюжин проектов, которые я поддерживаю из SCC, кажется менее разумным, чем восстановление из резервной копии и синхронизация по мере необходимости из SCC.

Какие стратегии резервного копирования, кроме контроля исходного кода, вы используете для обеспечения безопасности своего кода?

Подобный вопрос можно найти на https://stackoverflow.com/questions/38388/organization-wide-backup-strategy,, но мне больше интересно услышать личные стратегии других, если вам случится работать в организации, у которой нет общей стратегии. Я изложу свою стратегию в ответ.

Answer 1

Резервное копирование онлайн (Интернет) является важной частью процесса.

Все виды резервных копий на внешние диски обречены на провал, если они не сделаны назначенным персоналом (например, секретным). Если вы очень маленький магазин (или µ-ISV, такой как я), это не вариант. Даже тогда, где хранится внешний диск? Сейф с противопожарной защитой - единственный возможный хороший ответ. Хранить их вне офиса нехорошо: люди забудут принести их обратно в офис для периодического резервного копирования.

Резервное копирование на NAS является ИМХО лучшим решением, чем внешние накопители. Но в тот день, когда здание горит, резервные копии за пределами площадки - это ваш единственный шанс остаться в живых.

Я лично использую Mozy для резервного копирования основных локальных каталогов в дополнение к базе данных SCC.

Нет необходимости говорить, что шифрование AES-256 или аналогичное должно быть обязательным для хранения вашего исходного кода на чужих жестких дисках. Мозы и все его серьезные конкуренты предлагают его.

Answer 2

Я использую MozyPro , чтобы автоматизировать внешнее резервное копирование текущего кода на моей машине, а также базы данных контроля исходного кода. Это происходит постепенно каждую ночь.

Answer 3

Subversion: сервер управляется Beanstalk, клиент использует Tortoise SVN. После каждого сеанса кодирования все возвращается в репозиторий SVN, поэтому мне никогда не придется беспокоиться о потере кода. Я также периодически копирую последний код на CD и блокирую его в хранилище, чтобы быть уверенным!

Кроме того, имейте в виду, что ваш код является только одной частью уравнения. Большинство современных сред разработки требуют значительной настройки сами по себе (очевидным примером является интеграция сторонних инструментов, но простая установка IDE с соответствующими опциями также занимает довольно много времени). Таким образом, я также делаю всю свою разработку на виртуальной машине, которую я могу легко скопировать на внешний жесткий диск. Они также заперты в хранилище.

Наконец, я делаю резервную копию «справочной» базы данных, чтобы завершить картину. Я не могу просто сделать резервную копию схемы, потому что в моем продукте в базе данных хранятся важные системные данные (например, контент, поставляемый с веб-сайта).

Answer 4

Однако бывают случаи, когда ваша локальная копия не синхронизирована с хранилищем. Более того, некоторые проекты типа «песочницы», возможно, еще не сделали ;-) превратили его в SCC.

Во-первых, вы должны действительно постараться свести к минимуму время, когда ваш код «выходит» из SCC. Не для целей резервного копирования, но для отслеживания того, что было сделано, и особенно почему . комментарии неоценимы . Большая проверка, содержащая 3000 файлов с сообщением «Начальная редакция», не очень полезна.

Аргумент проектов песочницы имеет некоторый вес, но тогда вы должны просто обращаться с ним так же, как со всеми остальными файлами. Резервное копирование их на внешний USB-диск или что-то еще. Если вы не создаете резервные копии всех остальных файлов, я предлагаю вам начать сейчас.

И, конечно же, никто не хочет перестраивать весь каталог проекта из SCC, если диск умирает - гораздо лучше просто восстановить из реальной резервной копии.

Разве это не просто svn checkout? Почему бы просто не «восстановить из SCC»?

Answer 5

Помимо subversion, я использую crashplan для резервного копирования в автономном режиме. Он также может выполнять резервное копирование в локальное хранилище и на другие компьютеры (хотя, к сожалению, в настоящее время, по-видимому, требуется, чтобы один и тот же набор резервных копий хранился в каждом месте назначения - т.е. не может хранить небольшой набор жизненно важных вещей вне офиса и больший набор локально.)

Я также использую унисон (для вещей, которые слишком велики для резервного копирования вне сайта - музыку, фильмы и т. Д.) И временную капсулу OSX, так что в случае потери данных я могу надеяться на восстановление, не прибегая к онлайн-резервному копированию. Резервное копирование в онлайн-хранилище предназначено для таких стихийных бедствий, как сгорание или грабеж дома.

Answer 6

Я использую rdiff-backup для ежедневного инкрементного резервного копирования моего ноутбука по SSH. Он использует дельта-сжатие (например, rsync), поэтому он очень быстрый. Он также позволяет вам вернуться на любое количество дней к резервным копиям данных, чтобы вы могли вернуться назад сразу после завершения сложного кода, но до того, как вы случайно удалили его все.

Немного сложно начать, но, на мой взгляд, оно того стоит.

Answer 7

Если что-то не получится, я иногда отправляю по электронной почте важные сообщения, над которыми я работаю, на учетные записи веб-почты, такие как Yahoo или Hotmail. Я знаю, что все говорят о переходе с бумажного на цифровой, но иногда вы никогда не знаете, что произойдет, поэтому я распечатаю бумажные копии. Очевидно, что это не лучшее решение, особенно для большого проекта, поэтому я обычно ограничиваю печатные копии более мелкими, более важными частями. Я также, как правило, немного параноик, поэтому в итоге получу резервную копию резервной копии.

Answer 8

Поскольку я использую TFS (Team Foundation Server), я просто создаю резервную копию базы данных SQL Server, как и любая другая база данных, которую я использую