бэкап сервера что это
Серверные бэкапы
Если кибератаки, прогремевшие в этом году по всему миру, чему-то и научили, так это тому, как важны серверные бэкапы и избыточное хранение данных.
Хотя часть проблем связана с уязвимостями и эксплойтами нулевого дня, которые оставляют корпоративные сети без защиты, необходимость сберечь то невероятное количество данных, которое собрано, сохранено и обработано бизнесом, ставит перед нами особые задачи.
Серверные бэкапы важнейших данных, доступных по сети, направлены на решение и проблем кибератак, и проблем надёжного хранения данных. А именно:
Что такое серверный бэкап?
Серверы, предназначенные для резервного копирования данных, представляют собой мощные компьютеры, ответственные за хранение и защиту важных данных, которыми можно воспользоваться в максимально неблагоприятных условиях. Идёт ли речь об урагане, о длительном прекращении подачи электроэнергии или об искусной кибератаке, организациям нужны механизмы восстановления утраченных данных.
На локальных или облачных серверах можно создавать резервные копии файлов, папок, баз данных, жёстких дисков и других объектов. Это позволяет обеспечить постоянное хранение данных за пределами обычных сценариев их использования в виде сетевых ресурсов.
С ростом и развитием облачных решений бэкап-серверы стали заметной частью этих решений. Несколько компаний борются за рынок облачных бэкапов для бизнеса. Этот рынок находится вне рынка облачных хранилищ для обычных пользователей.
Как работают бэкапы в облачных средах?
С развитием облачных вычислений облачные службы помогают организациям защищать данные тремя способами. Причём это скорее не конкурирующие методологии защиты данных, а набор технологий, применяемых совместно.
Локальные и облачные бэкапы
Серверы организации или какие-то другие устройства (ленточные накопители, диски, флэш-накопители), хранящие копии имеющихся у организации данных и физически находящиеся в организации, представляют то, что называется локальными бэкапами. Они не зависят от сторонних организаций или от доступа в интернет. Они отличаются высоким уровнем доступности, и с их помощью можно восстановить данные быстрее, чем при использовании их удалённых облачных альтернатив.
Облачные системы резервного копирования данных, как и многие другие облачные решения, представляют собой услуги, предлагаемые облачными провайдерами, имеющими целые армии удалённых серверов и глобальных дата-центров. Услуги облачного резервного копирования имеются на общедоступных облачных платформах (например: AWS, Azure, GCP). Подобные решения могут быть развёрнуты и в самих организациях с использованием частной облачной инфраструктуры.
Сильные стороны облачных бэкапов включают в себя:
Гибридные системы резервного копирования данных и правило 3-2-1
Хотя свои плюсы есть и у облачных и у локальных бэкапов, не рекомендуется полагаться лишь на одну из таких систем или ограничивать количество резервных копий одним экземпляром.
Есть одно общепризнанное правило резервного копирования, которое получило название «правило 3-2-1». 
Правило 3-2-1
Смысл его заключается в следующем. Если имеются некие данные, которые нужно надёжно сохранить, надо сделать три копии этих данных. Одна из них — это те данные, которые доступны по сети. А вот ещё две копии должны быть записаны на носители информации разных типов. При этом одна из этих копий должна храниться за пределами организации. Например, в облачном хранилище.
Типы бэкапов
Полный бэкап
Дифференциальный бэкап
Инкрементальный бэкап
О важности оффлайн-бэкапов
В мае 2021 года хакеры атаковали сети энергетической компании Colonial Pipeline и мясоперерабатывающей компании JBS, зашифровав их данные. Компании, не имея доступа к сетевым ресурсам и опасаясь дальнейшей компрометации, решили остановить работу своих сетей и остановить производство. Многие другие компании в подобной ситуации поступают точно так же.
Одно из решений, позволяющих противостоять атакам шифровальщиков и вымогателей, представлено оффлайн-бэкапами. Если организацию атаковали — эти резервные копии данных остаются нетронутыми. В вышеприведённом примере злоумышленники, вооружившись программой-вымогателем, зашифровали данные, доступные по сети, не дав сотрудникам организаций и другим заинтересованным лицам нормально работать. В такой ситуации организациям имеет смысл рассмотреть вопрос о выплате выкупа, так как, если этого не сделать, диапазон проблем организаций может варьироваться от простоя до банкротства.
Если же в организации имеются оффлайновые серверные бэкапы, то восстановление данных можно выполнить буквально по щелчку пальцев (на выполнение этой процедуры, конечно, понадобится некоторое время, что зависит от размеров организации). Хотя оффлайновые бэкапы были ограничены использованием локальных серверов, теперь облачные сервисы резервного копирования данных предлагают SMB-доступ к масштабируемым удалённым серверным решениям.
Управление океаном данных
Данные могут быть и активом, и уязвимым местом организаций. Это актив, так как данные могут помочь в принятии бизнес-решений. Но это и обуза — из-за рисков, связанных с потерей данных. Правда, как бы там ни было, совершенно очевидно то, что к данным организаций нужно относиться со всей серьёзностью.
Разработка плана восстановления данных
В наши дни организации всех размеров зависят от хранимых ими данных. Это информация о сотрудниках и о клиентах, внутренние документы, код приложений, содержимое почтовых серверов и многое другое. Всё это — примеры данных, которые не должны попасть в чужие руки. Но гораздо легче говорить о «разработке плана резервного копирования и восстановления данных для корпоративной сети», чем этот план разработать и реализовать. Вот что мы можем порекомендовать тем, кто хочет защитить данные своей компании:
Защита данных — это важнейшее условие обеспечения непрерывности деятельности компаний
Угроза утечки данных — это то, мысль о чём не даёт спать по ночам специалистам по кибербезопасности. Повредит ли это репутации компании или будет означать правовые или финансовые риски — клиенты компаний, власти и сами организации относятся к данным очень серьёзно. Организации, в дополнение к секретной информации клиентов, хранят собственные данные, от которых зависит их конкурентоспособность.
Вот, кстати, материал о ПО для резервного копирования виртуальных машин.
Рынок систем для серверного бэкапа
Аналитики оценивают объём глобального рынка серверного резервного копирования данных в 2020 году примерно в 5 миллиардов долларов. К 2026 году объём этого рынка может удвоиться. Этот тренд указывает и на то, что бизнесу нужны средства для управления данными, которых становится всё больше и больше, и на необходимость срочной защиты того, что является самым ценным.
Услуги провайдеров облачных служб были и остаются популярными при решении таких задач, как хранение, синхронизация, резервное копирование данных. И если обычным пользователям привычны такие названия, как Dropbox, Google Drive и iCloud, бизнесу стоит пойти дальше общеизвестных сервисов для того, чтобы защитить свои данные. В частности, для организаций крайне важна возможность облачных платформ по непрерывной синхронизации изменений и по автоматическому созданию резервных копий данных.
Компании, предлагающие услуги серверного бэкапа
Бэкапы: подготовка к самому худшему
Глобальная экономика всё больше зависит от данных. Так как данные находятся в самом сердце всего того, чем мы занимаемся в цифровом мире, данные, по своей сути, стоят больших денег. Природные катаклизмы — явление редкое, но данным угрожают и цифровые угрозы: преступники, вредоносное ПО, человеческие ошибки. Поэтому бэкап-службы — это важнейшие части информационных систем. Тому, кто отвечает за информационные системы организации, стоит как можно скорее приготовиться к самому худшему и оценить, какие именно ценные данные имеются в компании, как в ней выполняются серверные бэкапы, как планируется восстанавливать её деятельность после возникновения чрезвычайной ситуации.
НЛО прилетело и оставило здесь промокоды для читателей нашего блога:
Сравнение способов резервного копирования
Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.
Конечно, идеальный способ, который бы всех устраивал, создать невозможно: везде есть свои плюсы и минусы. Но в то же время вполне реальным представляется подобрать способ, максимально подходящий под специфику конкретно проекта.
В этой статье мы расскажем об основных способах резервного копирования серверов под управлением Linux-систем и о наиболее типичных проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.
Схема организации хранения и восстановления из резервных копий
Часто причиной восстановления данных служит повреждение файловой системы или дисков. Т.е. бекапы нужно хранить где-то на отдельном сервере-хранилище. В этом случае проблемой может стать «ширина» канала передачи данных. Если у вас выделенный сервер, то резервное копирование очень желательно выполнять по отдельному сетевому интерфейсу, а не на том же, что выполняет обмен данных с клиентами. Иначе запросы вашего клиента могут не «поместиться» в ограниченный канал связи. Или из-за трафика клиентов бекапы не будут сделаны в срок.
Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.
Инкрементальное резервное копирование
При инкрементальном резервном копировании копируются только файлы, которые были изменены со времени предыдущего бэкапа. Последующее инкрементальное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. В среднем инкрементальное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, плюс данные всех последующих инкрементальных резервных копирований. При этом в отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.
С более подробной информацией о работе rsync можно ознакомиться на официальном сайте.
Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.
Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.
После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.
Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.
Дифференциальное резервное копирование
При дифференциальном резервном копировании каждый файл, который был изменен с момента последнего полного резервного копирования, копируется всякий раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все, что вам необходимо — это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервного копирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.
В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.
Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то стоит удалять/исключать ненужные вам файлы. Например, это могут быть кеши CMS. В таких кешах обычно очень много маленьких файлов, потеря которых не скажется на корректной работе сервера.
Полное резервное копирование
Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.
В большинстве публикаций по соответствующей тематике рекомендуется полное резервное копирование выполнять один или два раза в неделю, а в остальное время время — использовать инкрементальное и дифференциальное. В таких советах есть свой резон. В большинстве случаев полного резервного копирования раз в неделю вполне достаточно. Выполнять его повторно имеет смысл в том случае, если у вас нет возможности на стороне хранилища актуализировать полный бекап и для обеспечения гарантии корректности резервной копии (это может понадобиться, например, в случаях, если вы по тем или иным причинам не доверяете имеющимся у вас скриптам или софту для резервного копирования.
Рассмотрим их характерные особенности на примере:
Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.
Полное резервное копирование на уровне файловой системы
Типичный представитель: dump.
Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.
Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времени
Полное резервное копирование на уровне устройств
Например, с одним MySQL это будет выглядеть так:
* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Далее можно копировать снапшот в хранилище. Главное — следить за тем, чтобы во время копирования снапшот не самоуничтожился и не забывать, что при создании снапшота скорость записи упадет в разы.
Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.
Копировать снапшот можно с использованием докачки (например, rsync с патчем для копирования блочных устройств bugzilla.redhat.com/show_bug.cgi?id=494313), можно по блокам и без шифрования (netcat, ftp). Можно передавать блоки в сжатом виде и монтировать их в хранилище при помощи AVFS, и примонтировать на сервере раздел с бекапами по SMB.
Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.
К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.
Безопасность
Необходимо обезопасить себя от ситуации когда хранилище или ваш сервер будут взломаны. Если взломан сервер, то лучше чтобы не было прав на удаление/изменение файлов в хранилище у пользователя, который записывает туда данные.
Если взломано хранилище, то права бекапного пользователя на сервере так же желательно ограничить по максимуму.
Если канал резервного копирования может быть прослушан, то нужны средства шифрования.
Заключение
У каждой системы резервного копирования свои минусы и свои плюсы. В этой статье мы постарались осветить часть нюансов при выборе системы резервного копирования. Надеемся, что они помогут нашим читателям.
В качестве решений по резервному копированию, можно использовать supload и наше облачное хранилище.
Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.
Как правильно делать бэкапы и следить за ними
Введение
За столько лет я оброс всевозможными сервисами и услугами этого провайдера. Многим его советовал. Я туда десятки (может сотни) клиентов привел, в том числе через этот сайт. Долгое время у меня висела его реклама, так как я сам пользовался его услугами.
Последние дни торопливо переносил оттуда все критично важное (в основном в selectel). Оставил только то, что было оплачено заранее сильно вперед (например, дедики с оплатой на год). В связи с этой ситуацией, хотел еще раз обратить внимание на важность бэкапов и мои подходы к их созданию и обслуживанию.
Бэкапы нужно обязательно разворачивать и проверять
Мало просто настраивать мониторинг бэкапов и оповещения. Я регулярно вручную проверяю все бэкапы. Да, это очень хлопотно, но другого выхода я не вижу. Если я этого не делаю, то перестаю спокойно спать.
Вот свежий пример, когда большая продуктовая база бэкапилась, но бэкап не проверялся. Автору повезло, что потерял только несколько записей. А мог и всю таблицу. Там, где можно, я автоматизирую разворачивание на запасном сервере с помощью простых bash скриптов. У меня бывали всякие ситуации, когда бэкапы по каким-то причинам переставали делаться. Если они физически отсутствуют, я получаю уведомление от zabbix. Но этого мало.
Особенно важно проверять дампы баз. Физическое наличие файла с дампом не означает, что вы без проблем его развернете. Надо проверять данные, заливая дамп в базу. Это единственный способ убедиться, что данные реально есть и они актуальны.
Backup должен быть в другом дата центре у другого юр. лица
Вас могут банально заблокировать за неуплату, из-за ошибки. Хостер может разорвать отношения в одностороннем порядке. Все это я видел и встречал подобные истории от других. Вот пример из одного чата.
С самого сервера с данными не должно быть доступа к бэкапам
Для подобного рода бэкапов хорошо подходят бюджетные vps с большими дисками. Такая услуга, к примеру, есть у ruvds. В списке услуг выбирайте большой диск. Доступен не на всех тарифах и датацентрах.
Бэкапы должны быть максимально полные и подробные
Что я имею ввиду? Зачастую бэкапы делаются с расчетом на то, что что-то изменится на проде и нам надо будет развернуть бэкап и посмотреть на него. Бэкапятся, к примеру, исходники сайта и база к нему. Когда все в порядке и ты просто проверяешь бэкап, сложностей не возникает, потому что если ты даже что-то забыл, то залез на prod и посмотрел.
Например, у сайта может быть сложный и насыщенный конфиг nginx с кучей location и редиректов. В процессе эксплуатации вы могли тюнить и вносить много изменений в настройки mysql сервера. Если конфиги не забэкапить вместе с сайтом, то разворачивать и запускать его в работу может быть очень трудозатратно и хлопотно, особенно если оптимизация и настройки выполнялись давно и все уже забыто.
Backup виртуальных машин
Я знаю, что многие бэкапят целиком виртуалки. Я редко делаю такие бэкапы, так как с ними трудно работать. Получаются файлы огромных размеров. Если гоняете их через интернет, то они могут биться по дороге, либо в момент создания. У меня были ситуации, когда нужно было развернуть бэкап виртуальной машины на 200 Гб. Я несколько часов его заливал через интернет, а потом он не разворачивался из-за ошибки чтения. Пробовал несколько раз и каждый раз неудачно. Очень повезло, что заметил это в момент тестового разворачивания, а не тогда, когда была бы реальная авария. Это был бы полный провал, так как это был единственный экземпляр архивной копии.
Если нужно делать бэкап виртуальной машины, то я делаю небольшой системный диск (30-50 Гб) и бэкаплю только его. Данные кладу на отдельный виртуальный диск и забираю их в сыром в виде с помощью rsync или аналогов. С его помощью легко и быстро делать инкрементные бэкапы, а потом их разворачивать. Нет проблем с докачкой и битыми файлами. Даже если что-то и повреждено, то 1 файл из десятков тысяч погоды не сделает. Можно пережить.
Проверяйте скорость восстановления данных
В обычное время, во время проверок, этого можно не заметить, потому что спешить некуда. А вот если случилась авария и нужно как можно быстрее восстановить данные, скорость доступа становится очень критична.
Есть дешевые хранилища, где явно не указано, что скорость доступа будет низкой. Но нужно это понимать, если цена за хранение действительно ниже, чем в среднем по рынку. Многие хостеры на хранилищах с безлимитным трафиком на самом деле этот лимит имеют и включат вам его после того, как вы превысите определенный порог в скачанных данных. Вам просто сделают не 100 мегабит полосу, а 5-10.
У меня были ситуации, когда сервер с бэкапами живет на гигабитном порту с «безлимитным трафиком». А когда ты скачаешь 10-15 гигабайт, включается ограничение полосы до 100 мегабит. Возможно будет и дальнейшее урезание. С такими лимитами нет смысла платить за гигабит. Это просто маркетинговая уловка.
В общем, не доверяйте данным из описания тарифа, проверяйте их сами, чтобы потом не было сюрприза.
Заключение
Это мои основные правила создания бэкапов. А как вы делаете бэкапы? Поделитесь своим опытом. Возможно, я что-то забываю или упускаю.
Резервное копирование: где, как и зачем?
Защита данных предполагает наличие бэкапа — резервных копий, из которых можно выполнить их восстановление. Для большинства компаний и организаций резервное копирование данных относится к числу наиболее важных приоритетов. Около половины компаний работают со своими данными как со стратегическим активом. И ценность хранимых данных постоянно растет. Их используют для повышения качества обслуживания клиентов, поддержки текущей деятельности, исследований и разработок, учета, они задействованы в системах автоматизации, интернета вещей, искусственного интеллекта и др. Поэтому задача защиты данных от аппаратных сбоев, человеческих ошибок, вирусов и кибератак становится крайне актуальной.
В мире наблюдается рост киберпреступности. В прошлом году более 70% компаний подверглись кибератакам. Компрометация персональных данных клиентов и конфиденциальных файлов может иметь серьёзные последствия и приводить к огромным убыткам.
Вместе с тем появляется культура работы с данными, понимание того, что данные – это ценный ресурс, с помощью которого компания может получать дополнительную прибыль или сокращать издержки, а вместе с этим — и желание обеспечить надежную защиту своих данных.
Вариантов резервирования несколько: локальное или удаленное хранение резервных копий на собственной площадке, облачное хранение или бэкапы у хостинг-провайдеров.
Хранить и защищать
Как показывают результаты опросов, примерно четверть респондентов выполняет резервирование данных ежемесячно, столько же – еженедельно, и более четверти – ежедневно. И это вполне оправдано: в результате такой предусмотрительности почти 70% организаций избежали в минувшем году простоев из-за потери данных. В этом им помогают совершенствующиеся программные инструменты и сервисы.
Согласно исследованию IDC мирового рынка программного обеспечения репликации защиты данных (Data Replication and Protection), его продажи в мире будут расти с 2018 по 2022 годы ежегодно на 4,7% и достигнут 8,7 млрд. долларов. Аналитики DecisionDatabases.com в своем отчете (Global Data Backup Software Market Growth 2019-2024) пришли к выводу, что в ближайшие пять лет среднегодовые темпы роста мирового рынка программного обеспечения резервного копирования данных будут составлять 7,6%, и в 2024 году его объем достигнет 2,456 млрд. долларов против 1,836 млрд. долларов в 2019 году.
В октябре 2019 года Gartner представила «магический квадрант» по программному обеспечению резервного копирования и восстановления ИТ-систем дата-центров. Ведущими вендорами этого ПО стали Commvault, Veeam, Veritas, Dell EMC и IBM.
При этом растет популярность облачного резервного копирования: продажи таких продуктов и сервисов, по прогнозам, будут расти более чем вдвое быстрее рынка программного обеспечения защиты данных в целом. По прогнозу Gartner, уже в этом году до 20% предприятий будут использовать резервное копирование в облако.
По прогнозам Marketintellica, мировой рынок ПО для создания и хранения резервных копий на своей (on premises) и на сторонней площадке (off-site) в ближайшей перспективе будет стабильно расти.
По информации IKS Consulting, в России сегмент «облачное резервное копирование как сервис» (BaaS) увеличивается в среднем на 20% в год. По данным опроса Acronis 2019 года, компании все чаще полагаются именно на облачное резервное копирование: его используют более 48% респондентов, а около 27% предпочитают комбинировать облачное и локальное резервное копирование.
Требования к системам резервного копирования
Тем временем требования к программному обеспечению резервного копирования и восстановления данных меняются. Чтобы успешнее решать задачи защиты данных и оптимизировать расходы, компании готовы приобретать более простые, гибкие и недорогие решения, считают аналитики Gartner. Привычные методы защиты данных не всегда соответствуют новым требованиям.
Системы резервного копирования и восстановления данных должны предусматривать простое развертывание и администрирование, удобное управление процессом резервирования и восстановления, оперативное восстановление данных. Современные решения нередко реализуют функции репликации данных, позволяют автоматизировать операции, предусматривают интеграцию с облаками, встроенные функции архивирования, поддерживают аппаратные снимки данных.
По прогнозу Gartner, в ближайшие два года до 40% компаний перейдут на новые решения резервного копирования, заменив имеющееся ПО, а многие будут использовать одновременно несколько продуктов или сервисов, оптимально защищающих те или иные системы. Чем же их не устраивают прежние решения резервного копирования и восстановления данных?
Все в одном
Аналитики полагают, что в результате такого перехода компании получают более гибкие, масштабируемые, простые и производительные системы, нередко представляющие собой унифицированное программное обеспечения для управления данными и их хранения. Усовершенствованные продукты резервного копирования и восстановления включают в себя инструменты эффективного управления данными, дают возможность перемещать данные туда, где их хранение наиболее эффективно (в том числе автоматически), управлять ими, защищать и восстанавливать.
С ростом разнообразия и объемов данных важным требованием становится комплексная защита и управление данными: файлами, базами данных, данными виртуальных и облачных сред, приложений, а также доступ к различным типам данных в первичных, вторичных и облачных хранилищах.
Комплексные решения управления данными обеспечивают единое управление ими в масштабе всей ИТ-инфраструктуры: их резервное копирование, восстановление, архивирование и управления моментальными снимками. Однако администраторы должны четко понимать, где, как долго и какие данные хранятся, какие к ним применяются политики. Быстрое восстановление приложений, виртуальных машин и рабочих нагрузок из локального или облачного хранилища данных минимизирует простои, а автоматизация позволяет свести к минимуму ошибки из-за человеческого фактора.
Крупные организации с комбинацией унаследованных, традиционных и современных приложений нередко выбирают системы резервного копирования, поддерживающие широкий спектр операционных систем, приложений, гипервизоров и реляционных баз данных, обладающие высокой масштабируемостью (до нескольких петабайт и тысяч клиентов), а также предусматривающих интеграцию с широким спектром систем хранения данных, публичных, частных и гибридных облаков и ленточных накопителей.
Как правило, это платформы с традиционной трехуровневой архитектурой из агентов, медиа-серверов и сервера управления. Они могут объединять функции резервного копирования и восстановления, архивирования, аварийного восстановления (DR) и облачного резервного копирования, оптимизировать производительность, используя алгоритмы искусственного интеллекта и машинного обучения.
Как считают в компании Forrester, централизованное управление источниками данных, политиками, способность к надежному восстановлению данных и безопасность являются наиболее важными характеристиками решений резервного копирования.
Современные решения могут с любой периодичностью выполнять резервное копирование виртуальных машин на основе моментальных снимков практически без снижения производительности рабочих сред. Они ликвидируют разрыв между целевой точкой восстановления (Recovery Point Objective, RPO) и целевым временем восстановления (Recovery Time Objective, RTO), гарантируют доступность данных в любое время и обеспечивают непрерывность бизнеса.
Рост объемов данных
Тем временем в мире продолжается экспоненциальный рост объема создаваемых данных, и в ближайшие годы эта тенденция сохранится. По прогнозу IDC, объем создаваемых за год данных вырастет с 2018 до 2025 годы с 33 до 175 ЗБ. Среднегодовые темпы роста превысят 27%. На этот рост влияет и увеличение числа пользователей интернета. В прошлом году интернетом пользовались 53% населения Земли. Число пользователей интернета ежегодно увеличивается на 15-20%. Новые и развивающиеся технологии, такие как 5G, видео UHD, аналитика, IoT, искусственный интеллект, AR/VR, влекут за собой генерацию все больших объемов данных. Источниками роста объема данных также являются также развлекательный контент и видео с камер систем видеонаблюдения. Например, рынок хранения видео с камер наблюдения, по прогнозам MarketsandMarkets, будет расти на 22,4% в год и достигнет в этом году 18,28 млрд долларов.
Экспоненциальный рост объемов создаваемых данных.
За последние два-три года объемы корпоративных данных выросли примерно на порядок. Соответственно, усложнилась задача резервного копирования. Емкости хранилищ данных достигают сотен терабайт и продолжают увеличиваться по мере накопления данных. Потеря даже части этих данных может сказаться не только на бизнес-процессах, но и повлиять на репутацию бренда или на лояльность клиентов. Поэтому создание и хранение бэкапов в значительной мере влияет на весь бизнес.
Сориентироваться в предложениях вендоров, предлагающих свои варианты резервного копирования, бывает нелегко. Существуют разные варианты создания и хранения резервных копий, но наиболее популярными являются локальные системы резервного копирования и использования облачных сервисов. Резервное копирование в облако или в ЦОД провайдера обеспечивает надежную защиту данных и минимизирует риски, связанные с программными сбоями, техническими неисправностями оборудования и ошибками сотрудников.
Миграция в облака
Данные можно накапливать и хранить в собственных центрах обработки данных, но при этом придется обеспечить отказоустойчивость, кластеризацию и масштабирование емкости, иметь в штате квалифицированных специалистов по администрированию систем хранения. В этих условиях передача всех подобных вопросов на аутсорсинг провайдеру очень актуальна. Например, при размещении баз данных в ЦОД провайдера или в облаке можно возложить ответственность за хранение, резервирование данных, функционирование баз данных на профессионалов. Провайдер будет нести финансовую ответственность по соглашению об уровне обслуживания. Помимо прочего это позволяет быстро развернуть типовую конфигурацию для решения конкретной задачи, а также обеспечить высокую степень доступности за счёт резервирования вычислительных ресурсов и резервного копирования.
В 2019 году объем мирового рынка облачного резервного копирования составил 1834,3 млн. долл., и ожидается, что к концу 2026 года он достигнет 4229,3 млн. долл. при среднегодовом росте 12,5%.
При этом все больше данных будет храниться не в корпоративных сетях и не на конечных устройствах, а в облаке, причем, согласно IDC, доля данных в публичных облаках вырастет к 2025 году до 42%. Более того, организации переходят к использованию мультиоблачных инфраструктур и гибридных облаков. Такого подхода придерживаются уже 90% европейских компаний.
Облачное резервное копирование представляет собой стратегию резервного копирования данных, которая включает отправку копии данных по сети на сервер за пределами собственной площадки. Обычно это сервер сервис-провайдера, который взимает с клиента плату на основе выделенной емкости, пропускной способности или количестве пользователей.
Широкое внедрение облачных технологий и необходимость управления большими объемами данных способствуют росту популярности облачных решений для резервного копирования. Кроме того, с внедрением облачных решений резервного копирования связывают такие преимущества как простое управление и мониторинг, резервное копирование и восстановление в режиме реального времени, простая интеграция облачного резервного копирования с другими корпоративными приложениями, дедупликация данных и поддержка различных клиентов.
Ключевыми игроками данного рынка аналитики считают компании Acronis, Asigra, Barracuda Networks, Carbonite, Code42 Software, Datto, Druva Software, Efolder, IBM, Iron Mountain и Microsoft.
Мультиоблачные среды
Поставщики систем хранения данных делают все возможное, чтобы их продукты эффективно работали в мультиоблачной среде. Задача — упростить использование данных и перемещать их туда, где они необходимы, а их хранение — наиболее эффективно. Например, они применяют распределенные файловые системы следующего поколения, которые поддерживают единое пространство имен, обеспечивая доступ к данным в разных облачных средах, предлагают общие стратегии и политики управления в разных облаках и на локальном уровне. Конечная цель состоит в управлении, защите и эффективном использовании данных, где бы они ни находились.
Мониторинг — еще одна из проблем мультиоблачного хранения. Нужны инструменты мониторинга для отслеживания результатов в мультиоблачной среде. Независимый инструмент мониторинга, разработанный для нескольких облаков, позволит получить общую картину.
Прогноз роста мирового рынка систем управления мультиоблачными средами.
Совмещение периферийного и мультиоблачного хранения – также непростая задача. Чтобы эти системы эффективно работали вместе, нужно знать объемы и типы данных, где и как эти данные будут собираться, передаваться и сохраняться. Для планирования процесса потребуется также знать, как долго должны храниться данные каждого типа, где, когда и сколько данных нужно будет передавать между различными системами и облачными платформами, как осуществляется их резервное копирование и защита.
Все это поможет администраторам свести к минимуму сложности, связанные с объединением периферийного и мультиоблачного хранения.
Данные на периферии
Еще один тренд – периферийные вычисления. Как считают аналитики Gartner, в ближайшие годы около половины всех корпоративных данных будут обрабатываться за пределами традиционных ЦОД или облачной среды: все более значительная их доля размещается на периферии — для хранения и локальной аналитики. По прогнозу IDC, в регионе EMEA доля «периферийных» данных вырастет почти вдвое — с 11% до 21% от общего объема. Причины — распространение интернета вещей, перенос аналитики и обработки данных ближе к их источнику.
Переход от облачных и централизованных вычислений к периферийным вычислениям уже начался. Такие системы становятся все более востребованными. Затраты и сложность создания централизованной архитектуры для обработки большого объема данных чрезмерно велики, такая система может стать плохо управляемой по сравнению с распределением обработки данных по периферии или на соответствующем уровне сети. Кроме того, на периферии можно объединять или деперсонализировать данные перед отправкой в облако.
Данные за границей
Некоторые компании предпочитают хранить данные за рубежом, считая такой вариант надежной защитой данных от несанкционированного доступа и важным фактором снижения риска. Данные за границей – это гарантия защиты ценной информации. Размещенное за рубежом оборудование не находится под российской юрисдикцией. А благодаря шифрованию сотрудники ЦОД могут вообще не иметь доступа к вашим данным. В современных зарубежных дата-центрах используется высоконадежное оборудование, обеспечиваются высокие показатели надежности на уровне ЦОД в целом.
Использование иностранных ЦОД может иметь и ряд других преимуществ. Клиент застрахован от рисков, связанных с форс-мажорами или недобросовестной конкуренцией. Использование таких площадок для хранения и обработки данных позволит минимизировать подобные риски. Например, в случае изъятия серверов в России компания сможет сохранить копию своих систем и данных в зарубежных ЦОД.
Как правило, ИТ-инфраструктура зарубежных ЦОД – это стандарты качества, высокий уровень безопасности и контроля хранения данных. В них используются новейшие ИТ-решения, межсетевые экраны, технологии шифрования каналов связи, средства защиты от DDoS-атак. Энергообеспечение ЦОД также реализовано с высоким уровнем надежности (до TIER III и IV).
Резервное копирование в зарубежных ЦОД актуально для любого бизнеса в РФ, не работающего с персональными данными пользователей, хранение и обработка которых, согласно закону № 152-ФЗ «О персональных данных», должна осуществляться на территории России. Эти требования можно выполнить путем развертывания двух площадок: основной в России, где происходит первичная обработка данных, и зарубежной, где размещаются резервные копии.
Зарубежные площадки нередко используют и в качестве резервного ЦОД. Тем самым достигается максимальная безопасность и надежность, минимизируются риски. В ряде случаев они удобны для размещения данных и подключения к ним европейских клиентов. При этом достигается лучшее время отклика для европейских пользователей. Такие дата-центры имеют прямой доступ к европейским точкам обмена трафиком. Мы например предлагаем своим клиентам сразу 4 точки размещения данных в Европе — это Цюрих (Швейцария), Франкфурт (Германия), Лондон (Великобритания) и Амстердам (Нидерланды).
Что нужно учитывать при выборе дата-центра?
Используя услуги коммерческих ЦОД, помимо удобной структуры расходов, бизнес получает более гибкий сервис, который можно масштабировать в режиме реального времени, а оплачиваются только потребляемые ресурсы (pay-per-use). Услуги внешнего ЦОД также позволяют снизить риски, связанные с неопределенностью будущего, легко адаптировать ИТ к новым технологическим трендам, сосредоточиться на своих ключевых бизнес-процессах, а не на обслуживании ИТ-инфраструктуры.
Провайдеры учитывают при строительстве и эксплуатации своих площадок лучшие практики и международные стандарты, предъявляющие высокие требования к инженерным и ИТ-системам ЦОД, такие как ISO 27001:2013 Information Security Management (управление информационной безопасностью), ISO 50001:2011 Energy Management System (эффективное планирование систем энергоснабжения дата-центра), ISO 22301:2012 Business Continuity Management System (обеспечение непрерывности бизнес-процессов ЦОД), а также европейские стандарты EN 50600-x, стандарт PCI DSS, касающийся безопасности обработки и хранения данных пластиковых карт международных платежных систем.
В результате заказчик получает отказоустойчивый сервис, обеспечивающий надежный надежное хранение данных и непрерывность бизнес-процессов.