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

Question

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

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

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

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

Answer 1

Моя стратегия всегда проверять и создавать резервные копии всего хранилища.

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

Answer 2

В конце дня я проверяю свой код в системе контроля версий.

Около полуночи Мозы запускает и копирует мой код с сайта.

Около 1 часа ночи резервная копия блока SC копируется на ленту.

Примерно в 3 часа ночи Синхронизация SE просыпается и копирует мой код на внешний HD.

В течение дня мой рабочий ящик синхронизируется с моим домашним ящиком, используя Live Sync

Answer 3

OSX's Машина времени

Answer 4

(В дополнение к управлению исходным кодом на удаленном сервере) я использую бесплатную версию SyncBack (www.2brightsparks.com) и этот командный файл: (где аргументы для syncback.exe указывают ранее настроенные профили резервного копирования для синхронизации)

@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

с двумя 8 ГБ флешками каждый день. В конце недели я делаю то же самое, но затем нацеливаю на внешний жесткий диск настольного компьютера.

SyncBack великолепен!

Answer 5

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

Answer 6

Для всего, кроме самых простых 5-минутных тестов, я использую контроль версий, в моем случае Subversion.

Я использовал какое-то старое оборудование, на котором я запускаю linux, и сервер Subversion, которому я доверяю. Затем у меня есть сценарий cron, который архивирует хранилище (если оно было изменено с прошлого раза) каждую ночь и прикрепляет его по почте к моей учетной записи gmail с журналом изменений в теле. С ограничением вложения в 20 мегабайт в Gmail можно создать резервные копии всех, кроме наиболее двоичных репозиториев, с разбивкой файлов.

Я планирую переработать это, чтобы создать резервные копии на Amazon S3, но пока не успел это сделать.

Самая важная вещь IMHO - всегда иметь резервную копию где-то еще (географически), а не только на USB-диске или чем-то еще.

В случае очень маленьких 5 мин. тесты я помещаю их в свой DropBox (www.getdropbox.com).

Answer 7

никто не хочет перестраивать свои весь каталог проекта из SCC, если диск умирает

А? Мы всегда делаем это так. На самом деле у нас есть сервер сборки, который постоянно выполняет свежие сборки из чистой проверки. Если восстановление из резервной копии выглядит лучше, чем восстановление из SCC, вам нужно улучшить SCC.

Для всего кода, который не готов к производству, в SCC есть каталог с именами «детская площадка» и «мусор».

Answer 8

Я использую Microsoft SyncToy 2.0 для синхронизации каталогов моего проекта с папкой на сетевом ресурсе. У меня есть отдельные запланированные задачи, которые запускают разные сценарии SyncToy для разных каталогов (с разбивкой по версиям Visual Studio).

Answer 9

Я использую Mercurial в качестве моей системы контроля версий. Я использую хранилище на своем ноутбуке с Windows в качестве основного хранилища, но использую функцию клонирования Mercurial для резервного копирования его на свой сервер Ubuntu каждые два или три дня. Я также использую sync toy для резервного копирования важных каталогов на флэш-диск, включая копию репозитория, найденную на моем ноутбуке.

Answer 10

Хотя это субъективный ответ, я думаю, что вы не используете систему управления версиями должным образом.

Да, ваша локальная копия часто не синхронизирована с репозиторием, но любое данное изменение должно быть лишь небольшим объемом работы (например, вы не должны иметь вещи, которые не проверяются в течение нескольких дней подряд) , Если вы часто делаете коммиты, то в случае потери диска (кража / поломка и т. Д.) Вы теряете небольшое количество работы (обычно <1 день). </p>

Если вы делаете что-то совершенно сумасшедшее, что мешает другим разработчикам, тогда вы должны работать в ветке. Когда вы закончите, объедините ваши изменения обратно.

Вы также можете перестроить проект из своей системы SCC в любое время. Время от времени это полезно делать, просто чтобы убедиться, что все, что вам нужно собрать, находится в SCC - иногда файлы пропускаются, и вы никогда этого не замечаете, потому что вы всегда строите из рабочей копии, которую использовали для последние 6 месяцев.