Comments 41
Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами.
Так и получаются велосипеды =/
Я правильно понимаю, что вы написали свою версию rsnapshot?
А почему не использовали rsnapshot?
Я правильно понимаю, что инициация бекапа идет со стороны клиента (а не со стороны сервера, как в случае с rsnapshot)?
Посмотрел в исходники и не нашел
А почему не использовали rsnapshot?
Я правильно понимаю, что инициация бекапа идет со стороны клиента (а не со стороны сервера, как в случае с rsnapshot)?
Посмотрел в исходники и не нашел
cp -al. За счет чего получаются хардлинки между одинаковыми предыдущими копиями?
Нет, это все-таки немного попроще чем rsnapshot.
Rsnapshot не подошел как раз потому, что нам нужен бекап с клиентского сервера на сервер бекапов.
Хардлинки делает rsync c опцией -H
…
Rsnapshot не подошел как раз потому, что нам нужен бекап с клиентского сервера на сервер бекапов.
Хардлинки делает rsync c опцией -H
rsync --help…
-H, --hard-links preserve hard linksЭтот ключик я тоже искал и не нашел в rsync-backup.sh Надо искать где-то в другом месте?
А бекапы вы делаете на сервер в том же датацентре или в другом?
И, если таки хардлинки где-то делаются, то сколько это занимает времени на куче мелких файлов? Мы сделали себе аналогичную систему на rsnapshot, но
А бекапы вы делаете на сервер в том же датацентре или в другом?
И, если таки хардлинки где-то делаются, то сколько это занимает времени на куче мелких файлов? Мы сделали себе аналогичную систему на rsnapshot, но
cp -al на каталог с сотнями битриксовских сайтов занимает часы, если в бекапном сервере не ssd.
--link-dest=DIR
То есть делается первый бэкап после чего на него создается симлинк, с которым уже и сравнивается последующий. В случае совпадения — создается хардлинк на файл. Сейчас есть неудобство у скрипта в том виде какой он есть сейчас — если нужно подчистить бэкап — нужно удалить все хардлинки.
То есть делается первый бэкап после чего на него создается симлинк, с которым уже и сравнивается последующий. В случае совпадения — создается хардлинк на файл. Сейчас есть неудобство у скрипта в том виде какой он есть сейчас — если нужно подчистить бэкап — нужно удалить все хардлинки.
Насчет ключа, я не совсем прав был (скрипт не я писал), там немного по-другому:
--link-dest=DIR hardlink to files in DIR when unchanged
Насчет датацентров — по разному, иногда в одном и том же, иногда в разных странах серверы.
Хардлинки делаются не долго. Из цифр которые я приводил в конце статьи, это можно примерно понять.
--link-dest=DIR hardlink to files in DIR when unchanged
Насчет датацентров — по разному, иногда в одном и том же, иногда в разных странах серверы.
Хардлинки делаются не долго. Из цифр которые я приводил в конце статьи, это можно примерно понять.
UFO just landed and posted this here
Объясню почему не rsnapshot. в силу удаленности нашего сервера бэкапов, использование монтирования по ssh или NFS мы отмели за ненадежностью. В другом случае rsnapshot делать удаленный бэкапы не умеет, в силу как раз использования хардлинков (да суть та же rsnapshot работает на базе rsync). В нашем случае это удалось обойти использованием rsync сервера, почему к этому не пришли разработчики rsnapshot — не понятно :)
Есть мысль, что удалённому серверу виднее, когда у него сеть и диски менее нагружены. В итоге мы сделали бекапный сервер который по очереди в несколько потоков ходит ко всем клиентам и делает с них снапшоты. И работает это заметно быстрее, чем когда клиенты (особенно не доверенные) в произвольное время (обычно в полночь или 2-3 ночи по москве) массово начинают слать бекапы на сервер, у которого на дисках ~200 иопсов.
Кстати да, забыл почему-то написать — мы то это сделали как раз на rsnapshot — он умеет со стороны сервера ходить к клиентам по ссх и забирать оттуда данные по рсинк, например.
Этот вариант мы отмели из-за специфики работы. Имея большое количество серверов различных клиентов, очень не хочется оставлять дыру в виде рутового парольного доступа на ВСЕ сервера наших клиентов. Можете назвать это паранойей.
А как связаны наличие рутового, да ещё и парольного доступа и бэкап с удалённой машины?
А так вы наоборот оставляете дыру ещё большую: кто-то из клиентов может разобраться в вашей системе бэкапа, залезть на бэкапный сервер и стащить чужие бэкапы ( ну это если вы им вдруг рута выдаёте, хотя это не очень ясно из статьи. непонятных моментов после прочтения слишком много (: ).
А так вы наоборот оставляете дыру ещё большую: кто-то из клиентов может разобраться в вашей системе бэкапа, залезть на бэкапный сервер и стащить чужие бэкапы ( ну это если вы им вдруг рута выдаёте, хотя это не очень ясно из статьи. непонятных моментов после прочтения слишком много (: ).
Рута мы никому не даем, пока обслуживаем сервер.
имелось в виду «непарольного» для бэкапа с удаленной машины (если мы говорим о полном бэкапе контейнеров) нужен рутовый доступ на эту машину. ТО есть разработчики rsnapshot предлагают организовать доступ по ключу.
А что касается доступа на сервер бэкапа. тот тут все происходит по иному. За счет настроек rsync сервера во первых область хранения бэкапов конкретного сервера на едином сервере бэкапов зачрутена, да еще и предлагается ограничить IP с которого позволительно обращаться к этому хранилищу,
[$usernames]
comment = backups for $usernames
path = /home/$usernames/rsyncbackups
use chroot = true
uid = root
gid = root
log file = /var/log/rsyncd/$usernames.log
read only = false
write only = false
hosts allow = 1.2.3.4
hosts deny = *
transfer logging = false
То есть для хардлинков нужен рутовые права, и rsync сервер позволяет это организовать безопасно, поэтому был и выбран этот вариант на стороне сервера бэкапов.
А для операций ротации на стороне сервера бэкапов используется не привилегированный доступ. Для бэкапов каждого клиента заводится отдельный доступ.
А что касается доступа на сервер бэкапа. тот тут все происходит по иному. За счет настроек rsync сервера во первых область хранения бэкапов конкретного сервера на едином сервере бэкапов зачрутена, да еще и предлагается ограничить IP с которого позволительно обращаться к этому хранилищу,
[$usernames]
comment = backups for $usernames
path = /home/$usernames/rsyncbackups
use chroot = true
uid = root
gid = root
log file = /var/log/rsyncd/$usernames.log
read only = false
write only = false
hosts allow = 1.2.3.4
hosts deny = *
transfer logging = false
То есть для хардлинков нужен рутовые права, и rsync сервер позволяет это организовать безопасно, поэтому был и выбран этот вариант на стороне сервера бэкапов.
А для операций ротации на стороне сервера бэкапов используется не привилегированный доступ. Для бэкапов каждого клиента заводится отдельный доступ.
предлагается ограничить IP с которого позволительно обращаться к этому хранилищу,ssh тоже такое позволяет. см. AllowUsers в конфиге sshd. Так что rsync over ssh ничуть не уступает в этом плане.
То есть для хардлинков нужен рутовые праваМожно тут подробнее? Что вы имеете в виду?
Это я погорячился. Потребность в руте нужна для того что бы сохранить права файлов при бэкапе. rsync запускается с опцией -a, но очевидно что при отсутствии привилегий — этого не получится.
При бэкапе с правами всё отлично как раз. Проблемы начинаются при ротации бэкапов, если бэкапится директория, например, с правами 555 ( если ротация устроена по подобию реализации rsnapshot'a)
Однако, разработчики rsnapshot'a в качестве решения рекомендуют не использовать рутовый аккаунт, как это решили делать вы, а использовать более интеллектуальные средства рекурсивного удаления, например rmtree. Чуть подробнее можно прочитать тут.
Однако, разработчики rsnapshot'a в качестве решения рекомендуют не использовать рутовый аккаунт, как это решили делать вы, а использовать более интеллектуальные средства рекурсивного удаления, например rmtree. Чуть подробнее можно прочитать тут.
Тот, кто имеет доступ к бекапному серверу — в любом случае имеет доступ ко всем файлам.
У ssh ключей можно прописывать со стороны сервера какие команды разрешено запускать при авторизации по этому ключу — на сколько я понимаю — оставить только rsync — решает вашу задачу.
А вот _парольный_ доступ там в любом случае нигде не нужен.
У ssh ключей можно прописывать со стороны сервера какие команды разрешено запускать при авторизации по этому ключу — на сколько я понимаю — оставить только rsync — решает вашу задачу.
А вот _парольный_ доступ там в любом случае нигде не нужен.
Я правильно понял, что вы считаете, что rsnapshot умеет делать бэкап исключительно с локальной машины на локальную, т.к. всё завязано на хардлинки?
Или вам принципиально, чтобы именно клиент инициировал бэкап?
Или вам принципиально, чтобы именно клиент инициировал бэкап?
Кстати, вы смотрели на duplicity и dar? Если смотрели, то почему не подошло? Они быстрее rdiff-backup.
И, если я правильно догадываюсь по исходникам, что это для бекапа вдс на базе OpenVZ, то почему вы не переходите на ploop и на бекап его снапшотов, diff для которых за счет COW должен получатся даже меньше, чем как сейчас (сейчас большой изменившийся файл будет на бекапном сервере продублирован целиком, если изменится хотя бы его один байт).
И, если я правильно догадываюсь по исходникам, что это для бекапа вдс на базе OpenVZ, то почему вы не переходите на ploop и на бекап его снапшотов, diff для которых за счет COW должен получатся даже меньше, чем как сейчас (сейчас большой изменившийся файл будет на бекапном сервере продублирован целиком, если изменится хотя бы его один байт).
Честно говоря в контексте той задачи мы не рассматривали duplicity и dar. Хотя мы с ними знакомы.
В нашем случае принципиально было сделать легкое решение на базе rsync, поэтому не долго думаю мы начали писать свой скрипт.
Насчет контейнеров — верно. Мы практически везде их используем, но мы их неограничиваем. И использовать ploop для нас нет смысла, поскольку контейнер обычно занимает весь раздел.
В нашем случае принципиально было сделать легкое решение на базе rsync, поэтому не долго думаю мы начали писать свой скрипт.
Насчет контейнеров — верно. Мы практически везде их используем, но мы их неограничиваем. И использовать ploop для нас нет смысла, поскольку контейнер обычно занимает весь раздел.
Я подсел на btrfs — очень удобный механизм снапшотов и инкрементального удалённого бекапа:
btrfs subvolume snapshot -r /home /home/BACKUP-new
btrfs send -p /home/BACKUP /home/BACKUP-new | btrfs receive /backup/home
Каждый снапшот всё ещё новый блочный дивайс?
btrfs receive поверх ssh тоже работает?
btrfs receive поверх ssh тоже работает?
Каждый снапшот это как новая папка со своим блекджеком и… Можно примонтировать как девайс или работать как с папкой, если примонтировать уровень выше по дереву.
send — это сериализация состояния фс в файл, работать будет через любой пайп. А можно сохранить, передать и развернуть на удалённом сервере с помощью того же receive.
send — это сериализация состояния фс в файл, работать будет через любой пайп. А можно сохранить, передать и развернуть на удалённом сервере с помощью того же receive.
Я не понимаю, почему бы просто не использовать bacula/bareos? Зачем очередной велосипед? Тем более, если я верно понял, есть централизованный сервер. С ростом инфраструктуры поддерживать самописные скрипты — довольно накладно.
Bacula — хорошее решение для корпоративного сектора и это как раз то, что нужно когда одна контора, один центральный сервер. У нас не так — есть много клиентов и все бекапятся кто-куда, у многих есть свои серверы для бекапов. Всем настраивать бакулу не целесообразно. Просто зачем? Если всего два-три сервера и один сервер бекапов? И потом, нам критично быстрое восстановление из бекапа, а не ползанье по консоли бакулы (она может и не самая плохая, но все же с ней процесс замедляется).
Если один раз настроили сервер и отдали клиенту — тогда я понимаю (правда, я бы предпочёл более предсказуемый и оттестированный duplicity/duply), но я если я верно понял, то вы так же оказываете поддержку настроенным серверам. В этом случае разумнее использовать bacula/bareos. Там легко настраиваются различные стораджи (куда и какие бэкапы сливать), и есть веб-морды в которых есть права доступа, и бэкапы оттуда легко и быстро извлекаются.
Что непредсказуемого вы видите в нашем решении? Простой скрипт, все прозрачно.
P.S. Веб-морды это не наш метод. :) Только консоль, только харкор!
P.P.S. Да и с веб-мордами все не так очевидно. Если бы они еще заводились с пол-пинка и работали как надо на всех дистрибутивах (типа как Almir).
P.S. Веб-морды это не наш метод. :) Только консоль, только харкор!
P.P.S. Да и с веб-мордами все не так очевидно. Если бы они еще заводились с пол-пинка и работали как надо на всех дистрибутивах (типа как Almir).
10 лет назад пользовался для решения подобной задачи скриптом Bontmia: folk.uio.no/johnen/bontmia/
Откройте для себя obnam и не плодите велосипедов :)
Sign up to leave a comment.
Резервное копирование на удаленный сервер