Что преимуществом резервного копирования является файловая система программным обеспечением управления версиями?
Использование распределенного (не централизованного) контроля версии - это действительная стратегия резервного копирования, которая дополняет более обычные подходы резервного копирования. Для использования оба метода есть много способов.
Давайте рассмотрим, как работают стандартные резервные копии. Как правило, все файлы на файловой системе скопированы в некоторое удаленное местоположение. Это делается на некотором фиксированном периодическом графике, часто используя Cron. Это может включать в себя вариант инкрементных резервных копий, что означает, что некоторые резервные копии могут сохранять только дифференциров против существующей резервной копии. Обычно это делается для экономии места и обеспечивает больше резервных копий в данном пространстве. Если это так, то программное обеспечение резервного копирования также имеет задачу сборки выбранной резервной копии.
Плюсы:
- Состояние Все Файлы сохраняются в какой-то конкретной точке во время.
- Ни одна фактическая работа не требуется со стороны пользователя, по крайней мере, для Полностью автоматизированные резервные копии, которые являются нормой.
Минусы:
- Сохраненное состояние не имеет отношения к любому файлу. Это просто произвольная точка во времени.
- Ранее версии файлов в конечном итоге будут потеряны / выброшены в упражняться. Теоретически можно держать полную историю всех резервных копий, Но это редко делается по космическим причинам.
- состояние файла в данный момент во времени не сохраняется, потому что внутренних ограничений автоматизированной стратегии резервного копирования, которая Сохраняет снимки файловых систем на регулярных интервалах. Поставить его больше конкретно, если рассматриваемая файловая система была уничтожена, все Изменения, поскольку последнее резервное копирование будет потеряно.
- Нет способа знать, если резервная копия работает без Тестирование / взаимодействие с ним, хотя серьезное программное обеспечение для резервного копирования имеет Варианты для проверки. Это может быть особенно проблематично с Сжатые резервные копии.
Теперь сопоставляем это для резервных копий с использованием распределенного управления версией (DVCS). Существует два основных свободных распределенных система управления версиями, как я пишу это в начале 2015 года, а именно Git и Mercurial. Я думаю, что используя проприетарную версию Control Software - это плохое представление по ряду причин, поэтому я буду игнорировать существование таких зверей. Существует, конечно, другие распределенные системы управления версиями существуют, например BZR , , , [11755515], Монотон и ископается , но ртутные и Git Учет для большинства использования в пространстве DVCS.
Как можно сделать резервные копии с помощью DVCS? Очень просто. Обязаться к вашему репозитории, затем нажмите где-то еще, предпочтительно до удаленной машины в другом физическом месте, хотя прикрепленный USB-накопитель будет делать в щепоте.
Плюсы:
- Сохраненное состояние каждого файла по определению настроено и особенный для каждого файла.
- Репозиторий сохраняет полную историю снимка для каждого файла. Этот В конце концов, какая версия контроля означает.
- Можно сохранить локальное состояние каждого файла в очень короткие Интервалы, даже предполагающие, что человек не готов сделать правильный коммит. Это может сделать в Mercurial либо на использование очередей Mercurial Расширение , или новый развивается расширение . То Детали того, как это сделано, находятся за рамки этого поста, но Эффективный рабочий процесс - это очень прекрасное временное комбинирует, что может быть тогда объединено / изысканно / настроен в постоянные коммиты. Git имеет Подобная очередь Особенности . Насколько я знать. Гит не имеет ничего похожего на развитие.
- Нажатие на удаленные DVCS - это примитивный метод проверки, который Ваша резервная копия / репозиторий на удаленном машине живы и пинают. Хотя это не 100% гарантия (можно подтолкнуть к испорченные репос), по крайней мере, говорит вам, что вы делали коммиты ранее все еще присутствуют в удаленном репозитории справа хэши и так далее. Стандартные DVCS будут жаловаться громко, если Что-то выглядит несмотря на структуру удаленного репо
Минусы:
- Не все файлы будут сохранены, только те, которые под контролем версии.
- Обычно нецелесообразно ставить файлы за пределами определенного размера под
контроль версий. В случае Mercurial One начинает работать
Проблемы с производительностью с файлами около 10-20 МБ. Там разрабатывает / хаки, чтобы попытаться справиться с этим, в том числе
Barsfiles Mercurial Расширение а также знаменитый Git-Annex , у знаменитого Джои Гесс, но это не так далеко, насколько я знаю, замените правильно Стратегия резервного копирования. - Пользователь должен работать довольно сложно при настройке хранилища, делая совершает, писать сообщения журнала и, возможно, объединения и настройки Временные совершают постоянные коммиты.
Обратите внимание, что у меня намеренно сделали плюсы и минусы «стандартного резервного копирования» и «резервное копирование с помощью зеркальных изображений DVCS» друг друга. Снятие DVCS Con 2 будет производить точные зеркальные изображения. Как я уже говорил в начале этого поста, эти стратегии дополняют друг друга.
Обратите внимание, что DVCS Con 3 не совсем CON, потому что разумный пользователь должен использовать DVCS в любом случае, на мой взгляд.
Управление версиями и резервное копирование служат разным целям на разном уровне администрирования. В проектах вы контролируете и управляете своим кодом с помощью систем управления конфигурацией и контроля версий, а на системном уровне администраторы (IT-отдел или локальные администраторы) делают резервные копии каждого соответствующего хранилища данных (будь то домашние каталоги пользователей или базы данных производственных данных, или базы данных контроля версий проектов). В частной среде эта разница может быть не столь очевидна, но как только вы откажетесь от мнения, что оба служат "в какой-то степени одной и той же" цели "сохранения ваших данных", это должно стать вполне очевидным. Используйте контроль версий в своих проектах для получения надежных и воспроизводимых конфигураций программного обеспечения, а также используйте резервные копии для обеспечения безопасности данных для ваших систем (для предотвращения случайного или злонамеренного удаления данных, для отката данных в случае падения жесткого диска, пожара и т.д.).