Три ключевые стратегии резервного копирования данных

21 августа, 2024 admin

Предприятия всегда знали, насколько важно сохранять свои данные в безопасности — будь то копирование важных документов или приобретение огнестойких картотечных шкафов, компании имеют долгую историю резервного копирования данных, на которые они полагаются. И на то есть веская причина. Потеря критически важных для бизнеса данных может полностью потопить компанию.

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

Вот три ключевые стратегии, которые могут обеспечить или погубить успех резервного копирования компании.

Необходимо определить и донести ответственность.

В вашей компании нет ни одного человека, на которого не повлияла бы массовая утечка или потеря данных: конечные пользователи бизнес-систем не смогут выполнять свою работу, если данные отсутствуют или повреждены; руководителям высшего звена придется иметь дело с репутационным кошмаром; отделам ИТ-безопасности придется объяснять факт утечки аудиторам и, скорее всего, лишиться достигнутых ими статусов соответствия.

Это не обязательно означает, что все в бизнесе будут администрировать или управлять резервными копиями; управление резервными копиями обычно ложится на внутреннюю ИТ- или бизнес-системную команду. Однако все в бизнесе должны иметь возможность определить, кто отвечает за резервное копирование системных данных и как они могут сообщить об инциденте с данными. Компании, которые четко не определяют и не сообщают об ответственности за резервное копирование, постоянно оказываются в затруднительном положении, когда происходит инцидент.

Если вы думаете: «Это не я», подумайте еще раз. В 2022 году 76% руководителей ИТ-отделов сообщили, что их бизнес столкнулся с серьезной потерей критически важных данных. И поскольку бизнес-системы становятся сложнее, развертывания происходят чаще, а число конечных пользователей растет, вопрос больше не в том, «если» произойдет инцидент с данными, а в том, «когда».

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

Резервное копирование является ключевым компонентом Agile-разработки и DevOps.

Резервное копирование не только полезно с точки зрения безопасности и репутации, но и является ключевой частью вашего подхода Agile или DevOps.

Одной из четырех метрик DORA от Google , которая оценивает общую производительность и зрелость DevOps, остается «время восстановления сервисов». Google определила, что то, насколько быстро вы можете восстановиться после инцидента потери данных или простоя в ваших производственных средах, является ключевым показателем того, насколько надежны ваши процессы DevOps. Когда происходит инцидент, резервные копии закладывают основу вашей способности восстанавливать вашу среду, а план восстановления способствует тому, чтобы восстановление было выполнено быстро.

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

Именно в этом тонком балансе между скоростью и устойчивостью команды могут достичь истинных скоростных возможностей Agile и DevOps. Самые быстрые команды разработчиков программного обеспечения нацелены на доставку, а не на совершенство, и знают, что они могут быстро восстановиться и выполнить итерацию, даже если они вносят критические изменения.

Сравните самодельные инструменты резервного копирования с платформами BaaS.

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

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

Платформы Managed-backup-as-a-service (BaaS) готовы к использованию, и поставщики могут консультироваться по лучшим практикам резервного копирования и управления аварийным восстановлением. Для команд с большим объемом данных для резервного копирования и более сложными требованиями этот подход также может предоставить решение, доступное для менее технических членов команды. Стоимость часто является одним из главных возражений против управляемого BaaS, поэтому важно обсудить ваши конкретные потребности с поставщиками, поскольку у них может быть переменная модель ценообразования, которая увеличивается по мере масштабирования количества пользователей или объема резервных копий.

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

Резервное копирование: залог успеха

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