-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Glacier, backup restore (выделено)
- Автор темы c0dex
- Дата начала
Бекапы - достаточно сложная штука. Вот мне надо бекапить 50+ гб исходников фоток с быстрым доступом к ним - и варианты не так уж и очевидны. Облака ведут к vendor lock in, свои сервера - к затратам на администрирование.
Я даже решил писать свое комплексное решение с докером, чтобы можно было менять хранилище.
Я даже решил писать свое комплексное решение с докером, чтобы можно было менять хранилище.
Последнее редактирование:
Для быстроты доступа к бекапу иногда одним из самых оптимальных вариантов остается rsync/lftp + hardlink копии (в моем случае это обертка над ними - backupninja).
Взял 2 сервера по 10 евро в разных датацентрах на разных континентах с 1 TB винтами и шанс что случится что-то с 3 серверами (продакшен и 2 бекап сервера минимальны).
Плюс восстановление или доступ к данным за конкретный день быстро и удобно.
Но да, этот способ тупой как валенок и не хипстерский или энтерпрайзный. Зато способ дает дешевый вариант бекапа довольно больших объемов.
Взял 2 сервера по 10 евро в разных датацентрах на разных континентах с 1 TB винтами и шанс что случится что-то с 3 серверами (продакшен и 2 бекап сервера минимальны).
Плюс восстановление или доступ к данным за конкретный день быстро и удобно.
Но да, этот способ тупой как валенок и не хипстерский или энтерпрайзный. Зато способ дает дешевый вариант бекапа довольно больших объемов.
@Yoskaldyr, сразу возникает ряд вопросов:
* сколько лет эти сервера смогут работать без твоего внимания?
* что именно ты делаешь когда один из них отказал - тратишь день на настройку и синк нового сервера?
* как мониторится свободное пространство на дисках и что делать когда оно закончится?
у тебя есть решения, или ты "подумаешь об этом завтра"(С)?
c rsync есть проблема: это не бекап, это синхронизация, а чаще нужен удаленный storage с удалением, чтобы можно было интегрировать в инфраструктуру,
например, rsync-ом можно бекапнуть новую аватарку, но старую аватарку им не удалить не получится - нужен API
* сколько лет эти сервера смогут работать без твоего внимания?
* что именно ты делаешь когда один из них отказал - тратишь день на настройку и синк нового сервера?
* как мониторится свободное пространство на дисках и что делать когда оно закончится?
у тебя есть решения, или ты "подумаешь об этом завтра"(С)?
c rsync есть проблема: это не бекап, это синхронизация, а чаще нужен удаленный storage с удалением, чтобы можно было интегрировать в инфраструктуру,
например, rsync-ом можно бекапнуть новую аватарку, но старую аватарку им не удалить не получится - нужен API
Последнее редактирование:
Они и так работают без моего внимания - в мир смотрит только sshd и все. Как я сказал выше это не энтерпрайз или что-то новомодное.
Но я исхожу их того что все ломается даже супер пупер надежные амазоновские хранилища, из-за програмных косяков вылетают рейды, из-за криворукости какого-то индуса может слететь бекап где угодно.
Шанс что одновременно сломаются 2 сервера в различных датацетрах - минимален.
Настройка нового сервера занимает 1 час максимум, т.к. все делается 1 инсталл скриптом (установка нужных пакетов, загрузка готовых конфигов бекапа) + копирование новых ключей на продакшен сервер.
Если мне нужна будет вся история бекапа засинкаю ее с второго бекап сервера (1 команда) или же если можно забить на историю бекапов синк автоматом сделается по расписанию. Время свое на это я не трачу т.к. все в фоне происходит, но вообще-то все тут зависит от ширины канала между бекап сервером и продакшеном в также от размера синхронизируемых данных.
Как написал выше используется обертка backupninja, в которой и проверка свободного места и уведомления на почту, которая вообще-то может куда угодно бекапить, но отдельный физический сервер только для бекапов для меня предпочтительнее в плане удобства доступа к бекапам.
Я написал насчет такого метода бекапа, для случаев когда надо забекапить большие объемы картинок или чего-то подобного, и обычно для таких данных старые файлы не удаляются а только добавляются новые.
Просто с точки зрения цены и функционала (удобства доступа к бекапам и хранением ежедневной истории хотя бы за месяц) и размером хранилища хотя бы в 750гиг я не нашел ничего хоть немного приемлемого по цене как эти 2 выделенных сервера (в сумме 20евро) - все остальное было значительно дороже для таких объемов. Смотрел год назад сейчас может что-то для бекапа уже появилось.
понятно - свой велосипед типа vagrant
"от размера синхронизируемых данных" - это важный вопрос. Когда у нас миллион файлов на терабайт, rsync может выполняться не одни сутки.
А что такое история бекапов, и в каком она виде у тебя?
У каких провайдеров твои сервера?
"от размера синхронизируемых данных" - это важный вопрос. Когда у нас миллион файлов на терабайт, rsync может выполняться не одни сутки.
А что такое история бекапов, и в каком она виде у тебя?
нет, и я хочу это сделать, поэтому и расспрашиваю.
У каких провайдеров твои сервера?
Последнее редактирование:
Есть несколько серверов по такой технологии. Размер данных на обоих более 10млн файлов размером от 500 до 700 гиг.
В обоих случаях первый синк реально долго если rsync-ом, но тут помогает lftp в потоков эдак 20 или 30 и тогда все зависит только от пропускной возможности сети.
Инкрементальный бекап на всех серверах rsync-ом не больше 5 минут, точнее не замерял.
daily.1
daily.2
daily.3
...
weekly.1
weekly.2
...
monthly.1
monthly.2
при желании можно и почасовые прикрутить в дополнение будет что-то типа:
www.0
www.1
www.2
...
ovh, а точнее kimsufi. Взял в канаде и в европе (в канаде надо заказывать на штатовском сервере, на европейском сайте почти всегда показывает, что нет свободных в канаде). Если данных меньше 500 гиг, то можно взять у online.net - у них вообще за 6 евро есть сервера.
У овх очень нестабильные вдс, но сервера более менее норм, у моих клиентов и у меня в сумме стоит более 3-х десятков в разных датацентрах ovh - все нормально, ни разу не было проблем за полтора года с железом и только пару раз были проблемы связанные с нестабильностью канала (увеличение пинга), но это понятно, т.к. часто их ддосят их клиентов. Xотя конечно не сильно большая выборка чтобы сделать выводы о качестве.
Продакшен сервер у них нет смысла брать, ну разве что если нужен дешевый антиддос, но для сверх дешевого бекап сервера с большим объемом диска - самое оно.
Последнее редактирование:
у kimsufi главный недостаток - непредсказуемая доступность
Амазон сделал вот такую штуку, например https://aws.amazon.com/ru/storagegateway/ - драйвер с локальным кешированием
хранить 1 Tb на S3, не раздавая с него, будет стоить ~$30
учитывая, что у тебя винт заполнен на половину - скорее всего выйдет $15, т.е. чуть меньше, чем 2 сервера на kimsufi за $27
но это при условии доверия к S3 - сравнивать его надежность с роуторами кимцуфи я не готов
Амазон сделал вот такую штуку, например https://aws.amazon.com/ru/storagegateway/ - драйвер с локальным кешированием
хранить 1 Tb на S3, не раздавая с него, будет стоить ~$30
учитывая, что у тебя винт заполнен на половину - скорее всего выйдет $15, т.е. чуть меньше, чем 2 сервера на kimsufi за $27
но это при условии доверия к S3 - сравнивать его надежность с роуторами кимцуфи я не готов
Последнее редактирование:
@grigori, что-то это "немного" дороже 27$
https://aws.amazon.com/ru/storagegateway/pricing/
взял отсюда
https://aws.amazon.com/ru/storagegateway/pricing/
Gateway и S3 - это разные вещи, я сравниваю именно c S3
вместо Gateway есть и открытые решения на базе FUSE
https://github.com/s3fs-fuse/s3fs-fuse
https://github.com/joe42/CloudFusion
вместо Gateway есть и открытые решения на базе FUSE
https://github.com/s3fs-fuse/s3fs-fuse
https://github.com/joe42/CloudFusion
Последнее редактирование:
AnrDaemon
Продвинутый новичок
Это не проблема - это голый факт.
Писать бэкап прямо на удалённый сервер - проще себе в ногу выстрелить и не мучаться…
Бэкап пишется локально, потом синхронизируется с удалённым сервером.
@AnrDaemon, это понятно, речь о другом. Я об удалении по событию.
Только почему-то все ентерпрайз бекап-решения, да та же опенсорс бакула пишет сразу на удаленный сервер.
Понятно, что каждое конкретное бекап решение выбирается исходя из задач (критичности данных, необходимой скорости восстановления, количества свободных денег, необходимости ежедневных снепшотов, объема данных).
Также понятно что в некоторых случаях нужен бекап сразу в момент изменения какого либо файла (добавление, удаление и т.д.) и понятно для этого нужны какие специализированные решения.
В моем случае бекап нужен только для нескольких случаев:
Если продакшн сервер вдруг навернется внезапно полностью и бесповоротно - в зависимости от критичности проекта или последний ежечасный бекап или последний ежедневный.
Или если кто-то из менеджеров удалит что-то не то и проснется через пару недель, а т.к. обычно вспоминают что нужно что-то удаленное через пару недель или месяцев, то тут или один из ежедневных бекапов или из еженедельных/ежемесячных.
P.S. Если кто-то подскажет относительно недорогое решение с возможностью хранения снепшотов хотя бы за месяц для объема данных более 500гиг буду очень рад.
hell0w0rd
Продвинутый новичок
Что-то на бред похоже. Что делать когда данных много? В два-три раза больше дискового пространства держать?
И вот вопрос от молодого-зеленого, на реально больших проектах разве все не решается репликацией на уровне всего? То есть вот если я инстаграм, мне наверное нужно картинки бэкапить, но это не реально, поэтому просто буду держать реплики этих картинок и это будет бэкап на уровне приложения. Ну и аналогично с базой.
hell0w0rd
Продвинутый новичок
@MiksIr, ну я не зря привел именно instagram в пример. На одной из лекций в какой-то школе яндекса, ведущий пытал аудиторию расспросами, как бы они делали подобный сервис. Пришли к мнению, что достаточно сделать 3 реплики, тогда будет возможность определить, какая из реплик фоточки сломалась.
И я не согласен, это вопрос программирования, потому как плохую архитектуру (в тч и бэкапы) можно всегда затыкать дополнительными мощностями, а можно потратить часть этих денег для разработки системы получше.
И я не согласен, это вопрос программирования, потому как плохую архитектуру (в тч и бэкапы) можно всегда затыкать дополнительными мощностями, а можно потратить часть этих денег для разработки системы получше.
От сбоев вида "из-за ошибки в коде записали дерьмо поверх и весело везде среплицировали" это никак не защитит.
Впрочем, на сервисах типа инстаграмма обычно используется универсальный паттерн "да и х*й с ним".
