Вопрос: Что лучше для резервного копирования веб-сайта - rsync или git push


Я запускаю 2 веб-сервера LAMP на разных провайдерах для целей аварийного восстановления - высокопроизводительный живой сервер и низкопроизводительный сервер резервного копирования.

В настоящее время я каждый раз каждые 4 часа rsync все данные с живого сервера на сервер резервного копирования.

Это работает нормально, но загружает системную нагрузку, а rsync определяет, какие файлы были изменены.

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

Я должен был бы включить папку live uploads в git repo; и тогда процесс резервного копирования будет:

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch

а затем при каждом нажатии нажать кнопку фиксации сообщения на сервере резервного копирования для проверки.

Каждый сайт имеет размер от 50 до 2 ГБ. Я получаю около 50 отдельных git-репозиториев.

Является ли это «лучшим» решением, чем rsync?

  • Лучше ли вычислять, какие файлы изменились?
  • Является ли 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) папка 52M - без изменений

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

13
2017-12-27 13:32


Источник


как насчет «хорошего rsync»? Сигнализация загрузки системы - это именно то, что вы хотите: Завершите процесс AFAP, и это нормально, если это не мешает работе веб-сайта.
Спасибо. Я уже делаю «хороший rsync», который помогает - David Laing


Ответы:


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

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

Правило: когда дело доходит до резервного копирования и аварийного восстановления, ничто не может гарантировать вам 100% -ное восстановление.


3
2017-12-28 10:17





Rsync - замечательный инструмент синхронизации, но при использовании Git на сервере (серверах) вы получаете гораздо большую гибкость и pushили pullобновления.

Я должен отслеживать и копировать созданный пользователем контент на нашем сервере. production сервер имеет копию git repo, и каждую ночь он автоматически добавляет и фиксирует все новые файлы через cron. Это pushed на наш сервер gitolite, который затем использует крючки для синхронизации остальных серверов.

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

Я думаю, что вы в значительной степени хорошо разбираетесь в том, что оба предложения, я бы просто изменил вашу линию мышления с серверов, проверяющих / экспортирующих кодовую базу, на простое использование своих репозиториев. Другая мысль заключается в том, что вы могли бы rsync ваши медиафайлы (вы сказали, что 2GB для некоторых из этих сайтов, что заставляет меня думать, что есть много типов медиа-файлов?), А не отслеживать их в Git.


2
2017-12-27 21:06



Я добавил некоторые данные о производительности; что rsync почти всегда быстрее git. Тем не менее, мне нравятся ваши замечания о дополнительной силе предоставления git-репозиториев на реальном сервере - мне интересно, не лучший ли гибридный подход, с изменениями, внесенными в git-репо, а затем git-репозиции, которые были синхронизированы с резервной копией сервер ... - David Laing