хостинги гарантирующие сохранность данных при физических сбоях оборудования

У нас как бы тоже не 10 VPS на ноде... ну да ладно.

Ок, там же предлагают 2р/гб/месяц бекап-хранилище на 2гбитном канале, 5 рейд. Тариф такой. Мне как-то кажется, что если трафик местный, то себестоимость еще ниже...

extra, Если вы знаете магический способ, как бэкапить LVM-тома, да так, чтобы еще и без фриза, то буду премного благодарен за предоставленную информацию, готов буду даже заплатить или нанять для реализации данного проекта. Я недавно написал в нашей ветке, что у нас сейчас порядка 360 Тб клиентских VDS. Через 100-мбитный канал можем тянуть порядка 12 Мбайт/с и на перекачку всех данных нам понадобиться 8739 часов или, без одного дня, год времени ). Шутка ). Я понимаю, что канал на каждый сервер и он у нас гигабитый, но факт остается фактом. Гонять целиковые VDS-ы, не очень то рационально.

1. При правильно настроенной политике бэкапов, вы будете копировать только измененные файлы используя инкрементальное копирование. По этому трафик и время будут минимальными.

2. Хостер не имеет доступов к Вашей VDS и тем более не знает, что именно нужно бэкапить.

3. Учитывайте, что в большинстве случаев, хостер видит Ваши данные как раздел жесткого диска, а не как отдельные файлы. По этому хостеру придется бэкапить весь жесткий диск со всеми нулями свободного пространства, заказали вы виртуалку с 50 гигами, все 50 гиг будут улетать в бэкап независимо от реально занятого объема. Сразу скажу, сжимать такой архив крайне не выгодно, т.к. это во-первых, будет отъедать ресурсы CPU, во-вторых сильно удлинять время бэкапирования.

По-этому, на мой взгляд, самый оптимальный способ, если клиент будет сам бэкапить нужные данные. К тому же, большинство ответственных пользователей все равно сами делают бэкапы. Как показал случай, который лег в основу этой ветки, даже наличие системы резервного копирования у хостера не дает 100% гарантии сохранности данных. Как говориться - "И на старуху бывает проруха". Про то, сколько будет стоить гарантия от хостера 100% сохранности данных, Вам уже тут объяснили не один раз.

Естественно, ни один здравомыслящий хостер не желает потерять данные своих клиентов и всячески старается избежать ситуаций, при которых это может произойти. Но желания хостеров и клиентов не всегда совпадают с экономической реальностью вопроса.

Я конечно представляю, что каждый клиент мечтает, чтобы хостер делал ежедневный бэкап его данных, да еще хранил бы ежедневные копии хотя бы в течение месяца (50х30=1.5 ТБ под одного клиента только для бэкапов. 3 доллара говорите ;)?). А если этого не будет, и будет храниться только одна копия то какова вероятность, что в ней не окажутся уже сбойные данные, если вы не будете ежедневно следить за ними (или это опять должен будет делать хостер, знать какие у Вас сайты и как они должны работать?), а то знаете, у нас даже на шаред-хостинге (на котором у нас делаются ежедневные бэкапы и самая старая хранимая копия - трехмесячной давности) попадаются такие уникумы, у которых взломали сайт попортили все данные, а они очухались только тогда, когда взломанным сайтом уже перезаписались все архивные копии. А виноват опять хостер ).

Дальнейшие рассуждения могут нас подвести к аналогии с законом Яровой, когда для его обеспечения во всей стране и хранения данных в течение полугода со всех 29 тысяч серверных стоек которые имеются в России нужно построить еще 30 тысяч стоек.

В общем, реально, самый дешевый способ, это когда клиент бэкапит сам те файлы, которые ему реально важны, а не все подряд. Для этого, мы даже предложили клиентам отдельную услугу "Хостинг для резервного копирования", более того, наша тех. поддержка, помогает настроить необходимый бэкап-план. Дальше, остается только проверять, что копии исправно создаются (можно настроить уведомления на почту).

Ну и в конце могу добавить, что при правильно настроенном на VDS внутреннем бэкапе, восстановить данные получается гораздо быстрее в случае сбоя чем тянуть из архива 50 гигабайный диск и поднимать его на ноде.

---------- Добавлено 14.08.2016 в 03:47 ----------

Собственно говоря, я написал выше почему данный вариант экономически выгоден.

---------- Добавлено 14.08.2016 в 03:49 ----------

Да, и 5 рейд не очень оправдал себя по производительности, новый сервер уже собрали на 10 рейде.

Did you ever tried LVM snapshots backup like this?

Тю. У вас что в качестве нод? А в качестве хранилищ? А бэкапы хранятся одна штука за раз в неделю? Ну нихрена себе, бэкапы. Толку от такого практически ноль повдоль, лучше не делать совсем.

Вашу за ногу. Вам по полочкам рассказали. Давайте модель вашего СХД в офисе. Скажите, почему купили его. Сколько стоит коммутатор, к которому оно подключено и количество дисков. А я вам посчитаю стоимость гигабайта в месяц этого СХД.

Мля, развелось балаболов....

---------- Добавлено 14.08.2016 в 12:53 ----------

Цена вопроса. Сначала назовите параметры вышей виртуалки, создайте отдельную тему и вас тут накидают предложений как ё-маё. Только укажите в требованиях бэкап... ).

З.Ы. вообще все почти хостеры продают диск для бэкапов. Вот и покупайте, да настраивайтесь на него... ?

---------- Добавлено 14.08.2016 в 12:59 ----------

Оптимизайка, LVM очень сильно тормозит, когда диски боольшие и на них томов много. А PV's у хостеров, которые предоставляют VDS более-менее вменяемых за десятки терабайт.

Мы успешно бэкапим LVM тома, в том числе SWAP раздел (при наличии) + дамп RAM. Ровно так же успешно все это дело восстанавливаем в случае необходимости. Для XEN и KVM. Увы, наши наработки не продаются, но если вы действительно можете и готовы платить за know how, то имеет смысл обратиться в компании, которые специализируются на разработке коммерческих enterprise решений для резервного копирования виртуальных машин.

Как я уже отмечал ранее, тянуть ПОЛНЫЕ образы по сети это глупое решение (хотя знаю как минимум несколько хостингов, где делают именно так). Разумные мысли были в этой теме. Если кратко, то наш софт работает примерно так:

1) Делаем снапшот (LVM-тома + SWAP раздела + RAM dump)

2) Определяем изменившиеся блоки

3) Копируем только эти блоки на удаленное хранилище

4) Шифруем и архивируем до востребования

При восстановлении мы опять же не тянем ВЕСЬ архив образа, а только измененные блоки, что опять же экономит время и ресурсы. Надеюсь, данная информация будет полезна для вас и ваших клиентов.

Так ты их не разводи. Выше хостер тебе написал про присутствие экономической выгоды инкрементального бекапа. Произвольные параметры - 100гб, 200 рублей в месяц. Считаем, в разы ли это дороже или нет.

Если внимательно прочесть то, что я писал, то можно понять что я лишь уточнял насколько затратно хостеру делать бекапы своими силами, включая это в стоимость аренды вдс. Мне искренне непонятно было, почему стоимость такой услуги в разы выше, чем стоимость самого вдс. То ли ты невнимательно читал, то ли отвечаешь мне на какой-то иной вопрос.

Проводя манипуляции с софтом/железом на серваках/хранилищах с действующими клиентскими виртуалками хостер должен сделать бекап? Или это проблемы клиента, если у хостера что-то пойдет не так? Как поступают в таких случаях true-профи?

При хорошей дисковой подсистеме резервное копирование с помощью снапшотов не создает никаких проблем, Вы используете SSD, проблем не должно быть, максимум - легкая просадка производительности. Сжимать сам образ можно на лету (чтобы не тратить ресурс записи SSD дисков) при передаче данных куда-либо с помощью lzop (lzop.org). lzop меньше нагружает процессор, быстрее и лучше сжимает (по личным наблюдениям).

Еще есть такой момент - клиенты обычно не используют 100% емкость диска. Для рационального использования емкости дисков на сервере, а также решения проблем нулей при резервном копировании можно использовать thin lvm (за счет этого можно также повысить плотность размещения клиентов на сервере). В случае с KVM - виртуальная машина создается с thin lvm разделом, в качестве драйвера диска выбирается virtio-scsi, включается discard, внутри виртуальной машины разделы монтируются с discard. Что имеем на выходе? Реальное занятое дисковое пространство и отсутствием нулей :)

Из моей статистики одного сервера - выделено 300 гигабайт места, используется 150 гигабайт (50% от выделенного), резервные копии занимают 63 гигабайта (21% от выделенного).

Стоит отменить - что при таком подходе немного снижается производительность за счет того, что при каждой записи информации на диск требуется расширять или уменьшать динамический том LVM. И на момент резервного копирования за счет снапшота есть небольшая просадка производительности. Но в случае использования SSD дисков это практически незаметно.

Еще можете поискать про sparse backups, это более выгодно, если перекидывать резервные копии по сети (некое подобие инкрементального копирования).

Евгений Русаченко, SSD у нас больше половины клиентов, остальные на HDD дисках. Там будет вешалка при бекапах.

Требовать бекап от хостера (в случае виртуального сервера) = снять квартиру и заставить бабку-владелецу охранять квартиру под дверью круглосуточно. Странно звучит, да? Теоретически с ней можно договорится это делать за n сумму денег, но тогда аренда квартиры обойдется вдвое больше.

Я Вас понимаю как хостера, просто ответил на вопрос Вашего руководителя. С резервным копированием на HDD понятно, что будет печаль :)