Уместно ли делать резервную копию локальных репозиториев git через robocopy?
Всем привет.
Дополнением к вопросу. Делаю резервную копию диск-диск с помощью robocopy. На диске есть локальные репозитории под управлением GIT. Поскольку Git представляет собой файловую базу, то не произойдёт ли конфликта, если при таком копировании более новая версия базы перезапишет старую базу на диске резервного копирования? Не создаются ли в процессе работы git каких-то дополнительных файлов, которые после копирования будут конфликтовать с другими файлами в каталогах ".git" локальных репозиториев?
RoboCopy — крайне ненадёжная утилита. Часто просто пропускает файлы.
И это точно не средство резервного копирования. Используйте для резервных копий инструменты, поддерживающие VSS. Чтобы в копии у вас был мгновенный снимок состояния диска а не просто каша каких-то файлов без верификации.
Сергей Кузнецов, Можно пример, когда Robocopy тихо пропускает файлы? Например, вот статья с небольшим расследованием, где дело оказалось не в robocopy: https://habr.com/ru/post/261359/
Я сталкивался с ситуацией, когда robocopy не копировал файлы, но при этом подвисал на повторе. Да, немного неудобно, когда оставил резервное копирование на ночь, а утром увидел, что процесс дошёл только до середины. Но в той ситуации я запомнил исключения, которые для меня оказались не критичны и теперь это пропускается.
Alex XYZ, на ночь? Какой ужас ))
Инкрементная резервная копия обычно длится минут пять с двух терабайтного винта. На некоторых важных компах она у меня делается каждый час в течении рабочего дня. Ночью комп можно и выключить. В итоге имеется полный образ компа на любой час за последние пару суток, и дальше ежедневные копии за последние пару недель. RoboCopy так умеет?
Используем решения от Veeam + диск отформатированный в ReFS чтобы работала дедупликация.
Можно пример, когда Robocopy тихо пропускает файлы?
Мы проводили простые тесты. Копировали папку а потом сравнивали два каталога пофайлово в FAR Manager или Total Commander. Каждый раз чего-то не хватало. Хотя RoboCopy не выдавал никаких ошибок.
В итоге инструмент был признан неудовлетворительным в ни в плане надёжности, ни в удобстве. Хотя бы почитайте комментарии к статье, там и про другие грабли рассказывают.
Если каталог под управлением git скопирован целиком и содержимое копии идентично оригиналу -- всё будет ок.
У рабочих каталогов созданных командой git worktree внутри нет истории, только текстовая ссылка на каталог .git. Поэтому если всю эту конструкцию скопировать в другое место файловой системы и попытаться использовать там, то могут быть неожиданные эффекты, поскольку worktree будет ссылаться по абсолютному пути на оригинал, а не на копию.
Я планирую в случае проблем просто подключить диск с резервной копией вместо старого диска с сохранением буквы диска, поэтому если я буду использовать эту фичу, то не должно быть проблем.
