Поделиться
Краткий гайд по услуге BaaS: только важное
Полноценное руководство по резервному копированию зависит от типа и масштаба бизнеса и едва ли уместится в отдельную книгу. А вот важные моменты, актуальные абсолютно для всех, можно уместить в одной обзорной статье.
Когда бэкапы не помогут
Для организаций, которые обрабатывают огромные объемы данных, BaaS необходим, поскольку он снижает затраты на ИТ и обеспечивает надежную защиту от любых сбоев в работе с данными. Но для небольших компаний или организаций, которые не обрабатывают много данных, это может оказаться не самым экономичным решением.
Кроме того, если сотрудники мало используют цифровые сервисы и в основном общаются с клиентами по телефону или лично, время безотказной работы и мгновенного восстановления ИТ-сервисов может оказаться не столь важным. Это утверждение верно для всех компаний, не стремящихся к цифровой трансформации и избегающих всех цифровых сервисов.
И еще один нюанс: если интернет-соединение ненадежно, то облачные резервные копии также будут ненадежными. Если соединение медленное, то резервное копирование и восстановление займут много времени. Если соединение прервется, то возникает риск получить поврежденную или неполную резервную копию.
Создание бэкапа
Необходимо создать резервную копию всех данных компании, включая приложения, базы данных, аналитику, настройки, внутренний код, изображения, переписку, файлы журналов и сторонние API. При выборе поставщика услуг BaaS всегда полезно узнать, бэкап каких типов информации они поддерживают, а каких нет, чтобы не было сюрпризов.
Исходить следует из того, что важен каждый бит данных. В противном случае возможен риск оказаться в ситуации, когда системы успешно восстановлены, но некоторые из сторонних интеграций не работают. Если это так, то восстановление и запуск займут гораздо больше времени из-за переустановки, переподключения и перенастройки всех сторонних соединений.
При работе с SaaS-сервисами не стоит полагаться на то, что провайдер SaaS защитит от всех потерь. Наоборот — стоит предпринять дополнительные меры защиты в виде бэкапа всех данных из этого сервиса. В конце концов, в случае краха провайдер SaaS рискует лишь компенсациями по SLA, а клиент — огромным массивом данных. Более того, ответственность за данные индивидуальной учетной записи зачастую несет именно пользователь, а не платформа.
Время задержки при передаче больших объемов данных
Время задержки при передаче файлов небольшого размера гораздо проще удержать на минимальных значениях. В конце концов, файл маленький, процесс быстрый, передача информации несложная. Иное дело — большие архивы.
При работе с большими данными уже важна не только ширина канала связи, но и параллельная работа нескольких ИТ-служб с учетом их взаимного влияния, работа основного сервиса в период создания копии, отработка возможных обрывов связи или частичной передачи данных и других конфликтных ситуаций.
Существуют несколько способов изменить время задержки при передаче больших объемов данных, в частности:
- Использование более быстрых сетевых соединений: если задержка связана с пропускной способностью сети, можно обновить оборудование или провайдера, чтобы получить более быстрый доступ к сети.
- Оптимизация сетевых протоколов: можно оптимизировать протоколы передачи данных, чтобы уменьшить задержку. Например, можно уменьшить количество пакетов данных, увеличить размер пакетов или использовать более эффективные алгоритмы сжатия данных.
- Загрузка данных на более близкие серверы: если передача данных происходит на большие расстояния, можно загрузить данные на более близкие серверы, чтобы уменьшить время передачи.
- Распределение данных: вместо передачи одного большого файла, можно разделить его на несколько меньших файлов и передавать их параллельно, что может сократить время передачи.
Время восстановления больших объемов данных
Здесь все аналогично пункту выше: чем больше объем данных, тем сложнее процесс их восстановления, поэтому опираться на статистику восстановления малых файлов нельзя. Рекомендации по сокращению времени восстановления — те же.
Проведение реальных тестов
Время задержки при копировании и время восстановления должны быть проверены на практике на реальных данных и реальных сервисах в условиях их работы. Вот разве что с «работой» иногда можно немного пойти на компромисс и провести замеры не на живых сервисах, а в тестовой среде с имитацией живой нагрузки.
Стоит быть уверенным в том, что на этапе тестирования, максимально приближенного к реальной жизни, всплывут десятки нюансов, которые придется отрабатывать, и время внедрения облачного резервного копирования займет дни, недели или даже месяцы, вместо ожидаемых нескольких часов.
Шифрование данных
Для обеспечения безопасности данных рекомендуется использовать шифрование. Шифрование защитит ваши резервные копии от несанкционированного доступа и обеспечит конфиденциальность информации.
Бэкап как один из пунктов в бизнес-процессах
ИТ-ландшафт компании регулярно меняется: старые приложения используются все реже, новые набирают популярность. Вместе с этими изменениями неплохо бы корректировать и стратегию резервного копирования. Планы резервного копирования должны быть гибкими и адаптироваться к новым потребностям и изменениям ваших данных.
Проще всего это сделать в виде отдельного этапа в маршрутизации бизнес-процессов и алгоритме внедрения новых приложений. И пока ответственное лицо не подтвердит адаптацию BaaS под новое приложение, последнее не будет доступно сотрудникам компании.
Документирование
Самый скучный пункт. Тем не менее: документируйте процесс резервного копирования, включая расписание, использованные программные средства, место хранения и процедуры восстановления. Это поможет легко восстановить данные в случае чрезвычайных ситуаций или потери информации.
Заключение
Лучшие решения BaaS подобны тихому молчаливому партнеру. Они всегда присутствуют где-то в трее на заднем плане, но никто не замечает их работу до тех пор, пока они вам не понадобятся.
Короткая ссылка
