Borg backup
Понедельник, 6 марта, 2:44
Ищем альтернативу бекапам на основе tar + pigz и вот сейчас тестируем borg. У него отличная документация (хотя пока осталась пара вопросов), вот тестовый аккаунт клиента на 50 гигабайт — делаем бекап, в exclude — всевозможные кеши битрикса и подобный ненужный треш.
Выглядит как бы и неплохо, но — тут бекап делается на локальный ссд, в продакшене у нас делается tar + pigz на sshfs в другом датацентре в другой стране через гигабит и там архив занимает 17.3 гигабайта, причем последний раз он сделался за 10 минут. Пока подозреваю, что дело в том, что у pigz 12 потоков (в сервере 48 ядер).
Далее прекрасное — ждем час и делаем еще один бекап.
UPD: Многократные тесты в продакшене подтвердили — при копировании на удалённый сервер первый снапшот боргом происходит вдвое медленнее (20 минут borg с remote borg serve против 10 минут у tar+pigz в 12 потоков и sshfs), зато любой следующий снапшот занимает в пределах двух минут и пары мегабайт диска. Это фантастически хорошо по возможностям, которые оно даст и по количеству денег, которым нам сэкономит.
time borg create --compression lz4 -v --stats \
--exclude-from=exclude.cache \
/test.ssd/borg-test::b01 \
/vz5/private/$ve/home/$test_user/
------------------------------------------------------------------------------
Archive name: b01
Archive fingerprint: 054749329aa1393c4fdb9248c32e42d56b866fcc9b6c16c60433232445cecaaa
Time (start): Mon, 2017-03-06 01:50:16
Time (end): Mon, 2017-03-06 02:10:41
Duration: 20 minutes 25.22 seconds
Number of files: 437908
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
This archive: 21.13 GB 18.73 GB 14.49 GB
All archives: 21.13 GB 18.73 GB 14.49 GB
Unique chunks Total chunks
Chunk index: 273104 432909
------------------------------------------------------------------------------
real 20m28.493s
user 8m15.197s
sys 1m21.897s
Выглядит как бы и неплохо, но — тут бекап делается на локальный ссд, в продакшене у нас делается tar + pigz на sshfs в другом датацентре в другой стране через гигабит и там архив занимает 17.3 гигабайта, причем последний раз он сделался за 10 минут. Пока подозреваю, что дело в том, что у pigz 12 потоков (в сервере 48 ядер).
Далее прекрасное — ждем час и делаем еще один бекап.
Duration: 2 minutes 17.95 seconds
Number of files: 437909
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
This archive: 21.13 GB 18.73 GB 36.52 MB
All archives: 42.25 GB 37.47 GB 14.52 GB
Unique chunks Total chunks
Chunk index: 273934 865774
------------------------------------------------------------------------------
real 2m21.642s
user 1m39.310s
sys 0m17.626s
UPD: Многократные тесты в продакшене подтвердили — при копировании на удалённый сервер первый снапшот боргом происходит вдвое медленнее (20 минут borg с remote borg serve против 10 минут у tar+pigz в 12 потоков и sshfs), зато любой следующий снапшот занимает в пределах двух минут и пары мегабайт диска. Это фантастически хорошо по возможностям, которые оно даст и по количеству денег, которым нам сэкономит.
Borg — неудобности
Понедельник, 6 марта, 6:9
Минусов у Borg-а, конечно, есть. В основном всё написано в faq-е, и чувствуется, что вопросы популярные и у всех одинаковые — у меня возникли эти же вопросы примерно в этом же порядке. Это всё явно недостаток дизайна, конечно.
1) бекап нескольких серверов в один репозиторий. Мне бы его очень хотелось, потому что сотни битриксов хорошо задедуплицируются. Однако: каждый раз перебилд кеша + репозиторий лочится при записи — писать можно только в один поток. В оригинале:
"it will be most efficient if a single repository is only modified from one place. Also keep in mind that Borg will keep an exclusive lock on the repository while creating or deleting archives, which may make simultaneous backups fail."
2) взять сколько-то снапшотов из одного репозитория и закинуть в другой — штатных способов нет. Можно рсинком продублировать, замаунтить первый и добавить во второй, но только так. Учитывая пункт 1 (а именно из-за него вообще возникает сделать split репозиториев, или группу по префиксу выкинуть куда-то еще) — фича получается и ненужной.
По совокупности обоих пунктов, и учитывая, что юзеры могут переезжать между серверами — придется каждого юзера бекапить в отдельный репозиторий. Это плохо для дедупликации, конечно.
Менее очевидное:
Переменная BORG_FILES_CACHE_TTL по умолчанию = 20. Если какого-то файла нет в наборе более 20 раз — инфа о нем удаляется из кеша и при появлении файл будет залит заново в новый чанк. Так же — файлы привязаны к путям, датам и т.д. и, похоже, к инодам. Изменение пути файла приведет к его повторной загрузке. Это серьезный минус для дедупликации, но, вероятно, иначе нельзя сделать без потребления большого количества памяти как в ZFS.
Есть плохо понятный лимит количества метадаты, в который раньше все хорошо упирались, но сейчас вроде лимиты подняли так, что в реальной жизни проблемы возникать не должно.
В сравнении с альтернативами:
в bup сходу не завелись нужные фичи (поставил по доке, bup-index нету, exclude не сделать, про fuse в интернетах странное пишут и т.д.),
в zbackup странные авторы (fuse нет, авторы лучше меня знают какое мне надо сжатие, поэтому только самое медленное LZMA, нет возможность менять размер блоков/чанков, чтобы достать один файл надо распаковать всё — в моем случае, видимо, все 200 гигабайт и 15 миллионов файлов, есть больше памяти — в идеале от 512М против 64М у Borg и 10M у tar/pigz).
attic фактически умер два года назад и переродился в borg.
rsnapshot 99% времени (на миллионах файлов) создает симлинки — это всё.
duplicity сначала пишет много в /tmp и по факту я от него вообще ни разу ничего не дождался на моих объемах.
rdiff-backup — пробовали, всё было плохо, примерно как и с duplicity, очень плохо с большим количеством мелких файлов.
tartarus и backup2l, которы упоминаются в мануала хетзнера — совсем неинтересны в сравнении с Borg.
1) бекап нескольких серверов в один репозиторий. Мне бы его очень хотелось, потому что сотни битриксов хорошо задедуплицируются. Однако: каждый раз перебилд кеша + репозиторий лочится при записи — писать можно только в один поток. В оригинале:
"it will be most efficient if a single repository is only modified from one place. Also keep in mind that Borg will keep an exclusive lock on the repository while creating or deleting archives, which may make simultaneous backups fail."
2) взять сколько-то снапшотов из одного репозитория и закинуть в другой — штатных способов нет. Можно рсинком продублировать, замаунтить первый и добавить во второй, но только так. Учитывая пункт 1 (а именно из-за него вообще возникает сделать split репозиториев, или группу по префиксу выкинуть куда-то еще) — фича получается и ненужной.
По совокупности обоих пунктов, и учитывая, что юзеры могут переезжать между серверами — придется каждого юзера бекапить в отдельный репозиторий. Это плохо для дедупликации, конечно.
Менее очевидное:
Переменная BORG_FILES_CACHE_TTL по умолчанию = 20. Если какого-то файла нет в наборе более 20 раз — инфа о нем удаляется из кеша и при появлении файл будет залит заново в новый чанк. Так же — файлы привязаны к путям, датам и т.д. и, похоже, к инодам. Изменение пути файла приведет к его повторной загрузке. Это серьезный минус для дедупликации, но, вероятно, иначе нельзя сделать без потребления большого количества памяти как в ZFS.
Есть плохо понятный лимит количества метадаты, в который раньше все хорошо упирались, но сейчас вроде лимиты подняли так, что в реальной жизни проблемы возникать не должно.
В сравнении с альтернативами:
в bup сходу не завелись нужные фичи (поставил по доке, bup-index нету, exclude не сделать, про fuse в интернетах странное пишут и т.д.),
в zbackup странные авторы (fuse нет, авторы лучше меня знают какое мне надо сжатие, поэтому только самое медленное LZMA, нет возможность менять размер блоков/чанков, чтобы достать один файл надо распаковать всё — в моем случае, видимо, все 200 гигабайт и 15 миллионов файлов, есть больше памяти — в идеале от 512М против 64М у Borg и 10M у tar/pigz).
attic фактически умер два года назад и переродился в borg.
rsnapshot 99% времени (на миллионах файлов) создает симлинки — это всё.
duplicity сначала пишет много в /tmp и по факту я от него вообще ни разу ничего не дождался на моих объемах.
rdiff-backup — пробовали, всё было плохо, примерно как и с duplicity, очень плохо с большим количеством мелких файлов.
tartarus и backup2l, которы упоминаются в мануала хетзнера — совсем неинтересны в сравнении с Borg.
Ребрендинг конкурента
Вторник, 7 марта, 20:53
Был у селектела такой милый ламповый проект с дешевыми дедиками — tehnodom.com. И сайт у него был чудесный.
А тут вдруг раз и они сделали ребрендинг. Новый сайт — chipcore.com . Осторожно, глаза вытекают, не ходите туда, я предупреждал.
"Зачем они это сделали — лично я не понял." — наверное, лучший комментарий по этому поводу.
А тут вдруг раз и они сделали ребрендинг. Новый сайт — chipcore.com . Осторожно, глаза вытекают, не ходите туда, я предупреждал.
"Зачем они это сделали — лично я не понял." — наверное, лучший комментарий по этому поводу.
Датацентры
Пятница, 10 марта, 14:53
А вот скажите, если я пишу в требованиях "порт — 1 гигабит и нормальные цены", и "стоимость сервера до 7 т.р.", а мне потом разные продажники разных датацентров пишут и предлагают поставить сервера на коло за 4500 на 100 мегабит, и еще 30 т.р. за гигабит, а во втором случае предлагают взять сервер за 14 т.р. — это вообще что?
В обоих случаях ведь прочитали требования. В обоих случаях все не с улицы, а с хостобзорной тусовки. Ну какого?
Повторяется с разными компаниями с интервалом в три месяца, и так по кругу уже несколько лет.
В обоих случаях ведь прочитали требования. В обоих случаях все не с улицы, а с хостобзорной тусовки. Ну какого?
Повторяется с разными компаниями с интервалом в три месяца, и так по кругу уже несколько лет.
Странности с IPMI
Понедельник, 13 марта, 10:19
У нас тут странное случилось, переустанавливали ось на одном сервере по IPMI, там сначала мышка отвалилась, а потом вообще весь IPMI целиком. В смысле не просто iKVM, а вообще всё. Дальше много пытались ковырять, ipmi было мертво целиком даже после ребутов кнопкой.
Суппорт в ДЦ предложил (спасибо им) полностью выдернуть питание из сервера — после этого не только ipmi заработал, но еще и сервер стал работать в два раза быстрее. Включая, кстати, сеть — вдс-ки теперь мигрируются между серверами на 700+ мегабитах, а то я перед переустановкой оси как раз мигрировал их оттуда и с некоторым удивлением смотрел на миграцию на скоростях в 200-400 мегабит вместо привычных.
Нерешенной загадкой осталось почему сервер хронически отказывался грузиться в SATA DOM, но это я узнаю видимо уже не раньше следующих запланированных тех.работ.
Суппорт в ДЦ предложил (спасибо им) полностью выдернуть питание из сервера — после этого не только ipmi заработал, но еще и сервер стал работать в два раза быстрее. Включая, кстати, сеть — вдс-ки теперь мигрируются между серверами на 700+ мегабитах, а то я перед переустановкой оси как раз мигрировал их оттуда и с некоторым удивлением смотрел на миграцию на скоростях в 200-400 мегабит вместо привычных.
Нерешенной загадкой осталось почему сервер хронически отказывался грузиться в SATA DOM, но это я узнаю видимо уже не раньше следующих запланированных тех.работ.