Я запускаю 2 веб-сервера LAMP у разных провайдеров для аварийного восстановления - мощный рабочий сервер и маломощный сервер резервного копирования.
В настоящее время я синхронизирую все данные с живого сервера на сервер резервного копирования каждые 4 часа.
Это работает нормально, но увеличивает нагрузку на систему, пока rsync определяет, какие файлы были изменены.
Поскольку все веб-сайты также находятся в репозиториях git, мне интересно, будет ли git push лучшим методом резервного копирования.
Мне пришлось бы включить папку живых загрузок в репозиторий git; а затем процесс резервного копирования будет:
live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch
а затем иметь на сервере резервного копирования обработчик пост-фиксации для проверки при каждом нажатии.
Каждый веб-сайт имеет размер от 50 МБ до 2 ГБ. Я бы получил около 50 отдельных репозиториев git.
Это «лучшее» решение, чем rsync?
Спасибо!
---- Данные некоторых сравнительных тестов ------
1) Папка 52 МБ, затем добавление новой папки 500 КБ (в основном текстовые файлы)
rsync
sent 1.47K bytes received 285.91K bytes
total size is 44.03M speedup is 153.22
real 0m0.718s user 0m0.044s sys 0m0.084s
мерзавец
Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)
real 0m0.074s user 0m0.029s sys 0m0.045s
2) Папка 1.4G, затем добавление новой папки 18M (в основном изображений)
rsync
sent 3.65K bytes received 18.90M bytes
total size is 1.42G speedup is 75.17
real 0m5.311s user 0m0.784s sys 0m0.328s
мерзавец
Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)
real 0m15.334s user 0m5.202s sys 0m1.040s
3) Папка 52M, затем добавление новой папки 18M (в основном изображений)
rsync
sent 2.46K bytes received 18.27M bytes 4.06M bytes/sec
total size is 62.38M speedup is 3.41
real 0m4.124s user 0m0.640s sys 0m0.188s
мерзавец
Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)
real 0m6.990s user 0m4.868s sys 0m0.573s
4) Папка 1.4G, затем добавление новой папки 500k (в основном текст)
rsync
sent 2.66K bytes received 916.04K bytes 612.47K bytes/sec
total size is 1.42G speedup is 1547.14
real 0m1.191s user 0m0.180s sys 0m0.268s
мерзавец
Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)
real 0m1.776s user 0m0.390s sys 0m0.497s
5) Папка 1.4G - без изменений
rsync
sent 1.72K bytes received 716.44K bytes 287.26K bytes/sec
total size is 1.42G speedup is 1979.18
real 0m1.092s user 0m0.168s sys 0m0.272s
мерзавец
nothing to commit (working directory clean)
real 0m0.636s user 0m0.268s sys 0m0.348s
5) Папка 52М - без изменений
rsync
sent 528 bytes received 88.40K bytes 59.29K bytes/sec
total size is 62.38M speedup is 701.41
real 0m0.779s user 0m0.044s sys 0m0.144s
мерзавец
nothing to commit (working directory clean)
real 0m0.156s user 0m0.057s sys 0m0.097s
На самом деле я бы предложил использовать сбалансированное сочетание того и другого. Ваша основная резервная копия должна (как минимум) каждую ночь передаваться в git. Синхронизируйте его один или два раза в неделю с другим компьютером, который находится подальше от производственной коробки, с помощью rsync.
Git поможет вам с немедленным восстановлением, а также упростит анализ данных благодаря тому, что ваша резервная копия имеет версию и журнал изменений. После любого серьезного изменения данных вы можете выполнить фиксацию и вручную нажать на git и указать причину в журнале изменений. В случае, если git выйдет из строя, тогда на помощь придет rsync, но имейте в виду, что вы все равно потеряете данные в зависимости от частоты rsync.
Практическое правило: когда дело доходит до резервного копирования и аварийного восстановления, ничто не может гарантировать 100% восстановление.
Rsync - замечательный инструмент для синхронизации, но вы получаете гораздо больше универсальности при запуске Git на сервере (ах) и pushing или pullобновления.
Мне нужно отслеживать и создавать резервные копии пользовательского контента на нашем сервере. В production На сервере есть копия репозитория git, и каждую ночь он автоматически добавляет и фиксирует все новые файлы через cron. Это pushed на наш сервер gitolite, который затем использует хуки для синхронизации остальных серверов.
Поскольку на серверах есть копии репо, вы получаете не только снимок, но и подробную информацию истории, которая может легко спасти вас, если с вашим сервером что-нибудь случится.
Я думаю, что вы в значительной степени хорошо понимаете, что предлагают оба, я просто изменил бы ваше мышление с серверов, проверяющих / экспортирующих кодовую базу, на просто наличие собственных репозиториев. Другая мысль заключается в том, что вы можете синхронизировать свои медиафайлы (вы сказали 2 ГБ для некоторых из этих сайтов, что заставляет меня думать, что существует много типов медиафайлов?) И не отслеживать их в Git.