Подтвердить что ты не робот

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

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

EDIT. У меня есть несколько проектов в моих каталогах проектов. Не все находятся в текущем развитии, но любой из них, возможно, потребуется "исправлять" всякий раз, когда обнаруживается ошибка. Восстановление одного, активного проекта из SCC представляется вполне разумным. Восстановление всех из нескольких десятков проектов, которые я поддерживаю от SCC, кажется менее разумным, чем восстановление из резервной копии и синхронизации по мере необходимости с SCC.

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

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

4b9b3361

Ответ 1

Моя стратегия всегда регистрируется и резервирует весь репозиторий.

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

Ответ 2

В конце дня я проверяю свой код на исходный код.

Около полуночи Mozy запускается и резервирует мой код за пределами сайта.

Примерно в 1:00 ящик SC будет скопирован на ленту.

Около 3 утра Syncback SE просыпается и возвращает мой код на внешний HD.

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

Ответ 3

(В дополнение к управлению версиями на удаленном сервере) я использую бесплатную версию 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 - это здорово!

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

Я использую Unison для репликации всего моего домашнего каталога на двух разных машинах дома. Таким образом, если я неаккуратно или у меня есть 20-летние файлы, не находящиеся под контролем источника (.emacs), у меня все еще есть мера защиты. Я также копирую все, кроме личных файлов (фотографии, музыку), на машине на работе.

Ответ 12

Контроль версий (SVN) для меня более чем достаточно. Тем не менее, существуют некоторые правила:

  • Я совершаю как можно чаще (4-6 часов работы без фиксации уже начинают создавать это покалывающее ощущение чего-то не так).
  • SVN-структуры решений всегда являются атомарными. Вам просто нужен свежий CheckOut, чтобы иметь возможность запускать интеграцию "rebuild-copy-package" script в любом решении (для запуска тестов может потребоваться установка параметров подключения к DB до этого).
  • Сервер SVN является надежным и регулярно резервным копированием.
  • Изменения распространяются между различными решениями, составляющими приложение (т.е. из открытой библиотеки с открытым исходным кодом, во внутренний код, который использует его) только через коммиты (сервер интеграции выбирает это и создает пакеты, которые могут быть использованы в решениях вниз -stream).
  • Проекты Sandbox (прототипы) всегда хранятся в папке Prototypes SVN (sibling of Trunk или Tags), которая называется "YYYY-MM-DD PrototypeName"

Ответ 13

НЕ ИСПОЛЬЗУЙТЕ BIDIRECTIONAL SYNC TOOLS ДЛЯ BACKUP

... ну, по крайней мере, не автоматически

Инструменты синхронизации, такие как унисон, синхронизируют два (или более) местоположения. Таким образом, если вы случайно испортили файл в одном месте, беспорядок будет преобразован в другой, и вы не заметите.

Ответ 14

Мы также проверяем все (сначала и часто, и часто), и создаем резервную копию всего репозитория (CVS) с tar и ftp на наш резервный сервер.

Ответ 15

Когда вы пишете то, что еще не принадлежит к основной сборке, создайте ветку. Когда он войдет в основную сборку, объедините свою ветку с ней.

Распределенные VCS также упрощают локальные ветки, центральный репозиторий никогда не узнает, что они существуют.

Резервное копирование локального репозитория (распределенного VCS) путем нажатия изменений на удаленную копию настолько тривиально, что я использую git в качестве основного метода резервного копирования для большинства документов, файлов конфигурации, в основном ничего не двоичного.

Ответ 16

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

Ответ 17

Я работаю над продуктом под названием "Агент Transactor Code", который предназначен только для того, что вы просите.

Он обеспечивает локальное резервное копирование и контроль версий для ваших исходных файлов.

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

Бета-версия должна появляться в январе.

Вы можете увидеть наш "сайт" (это немного грубо) в

www.transactor.com

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

Update:

Здесь немного больше информации, основанной на некоторой обратной связи, которую я получил в комментариях:

1) У меня есть что-то еще в контроле источника?

Нет! Я считаю, что контроль источника - замечательная вещь. При правильном использовании он предоставляет огромный инструмент для управления жизненным циклом программного обеспечения.

Но, когда он используется правильно, управление исходным кодом оставляет большой пробел, поскольку он не защищает работу разработчиков до его завершения. Что нужно, это то, что фокусируется на работе отдельных программистов. Агент кода делает это.

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

Code Agent - это инструмент, призванный облегчить вашу жизнь (потому что он гарантирует, что ваша работа всегда сохраняется).

Ответ 18

Код, который не проверен (и, следовательно, резервное копирование) на ваш VCS, не существует. Это не более реальный, чем код, который у вас только есть в голове. Это действительно так просто.

Ответ 19

Я использую продукт (который я написал, это мой микро-isv), называемый Transactor Code Agent. Его резервный инструмент, разработанный специально для программистов.

Он отслеживает ваш исходный код, и каждый раз, когда вы сохраняете изменения, он поддерживает его и сохраняет локальную историю для вас.

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

  • Source Control предназначен для управления изменениями, чтобы помочь вашей программе перейти из одного согласованного состояния в другое.
  • Вам не нужно беспокоиться о том, чтобы поддерживать частную ветку
  • Вам не нужно прерывать работу, чтобы делать проверки исключительно для целей резервного копирования. Вы можете просто сосредоточиться на написании кода и проверять свои материалы, когда это будет сделано.

Вы можете скачать демо-версию здесь:

http://www.transactor.com/download

Ответ 20

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

Ответ 21

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

Ответ 22

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

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

Ответ 23

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

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

Ответ 24

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

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

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

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

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

Ответ 25

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

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

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

Ответ 26

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

Ответ 27

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

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

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

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

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

Ответ 28

joel от joelonsoftware сказал в каком-то сообщении, что если для создания и развертывания вашего проекта требуется более двух командных строк (или более одной минуты при подготовке), вы делаете это неправильно. Я полностью согласен с ним, и я думаю, что SCM должно быть достаточно. системы резервного копирования предназначены только для катастрофических катастроф (сбоев hdd, пожара и торнадо).