86. Резервное копирование всех платформ
Содержание
Резервное копирование всех платформ
В ходе всего этого задания мы обсудили множество различных платформ и сред. Всех их объединяет то, что все они нуждаются в определенном уровне защиты данных!
Защита данных существует уже много лет, но богатство данных, которые мы имеем сегодня, и ценность, которую эти данные приносят, означает, что мы должны быть уверены не только в устойчивости к сбоям инфраструктуры за счет наличия нескольких узлов и высокой доступности приложений, но мы также должны учитывать, что нам нужна копия этих данных, этих важных данных в безопасном и надежном месте, если произойдет сбой.
В наши дни мы часто слышим о киберпреступности и программах-выкупах, и не поймите меня неправильно - это серьезная угроза, и я уверен, что вы подвергнетесь атаке программ-выкупов. Это не вопрос “если”, это вопрос “когда”. Поэтому еще больше причин убедиться в том, что ваши данные надежно защищены на тот случай, если такое время настанет. Однако самой распространенной причиной потери данных является не выкупное ПО или киберпреступность, а просто случайное удаление!
Мы все это делали, удаляли то, что не должны были удалять, и тут же сожалели об этом.
Несмотря на все технологии и автоматизацию, о которых мы говорили в этой статье, требование защищать любые данные с состоянием или даже сложные конфигурации без состояния все еще существует, независимо от платформы.
Но мы должны быть в состоянии выполнить эту защиту данных с учетом автоматизации и возможности интеграции в наши рабочие процессы.
Если мы посмотрим, что такое резервное копирование:
В информационных технологиях резервная копия или резервное копирование данных - это копия компьютерных данных, снятая и сохраненная в другом месте, чтобы ее можно было использовать для восстановления оригинала после потери данных. Глагольная форма, обозначающая процесс создания такой копии, - “резервное копирование”, а существительное и прилагательное - “резервное копирование”.
Если мы разберем это в самой простой форме, то резервное копирование - это копирование и вставка данных в новое место. Проще говоря, я могу сделать резервную копию прямо сейчас, скопировав файл с диска C: на диск D:, и у меня будет копия на случай, если что-то случится с диском C: или что-то будет неправильно отредактировано в файлах. Я могу вернуться к копии, которая находится на диске D:. Теперь, если мой компьютер умрет, где находятся оба диска C и D, я не буду защищен, поэтому мне придется искать решение или копировать данные вне моей системы, может быть, на NAS-накопитель у себя дома? Но тогда что произойдет, если что-то случится с моим домом, может быть, мне нужно подумать о хранении данных на другой системе в другом месте, может быть, облако - это вариант. Может быть, я могу хранить копии важных файлов в нескольких местах, чтобы снизить риск сбоя?
3-2-1 Методика резервного копирования
Сейчас самое время поговорить о правиле 3-2-1 или методологии резервного копирования. На самом деле я провел lightening talk, посвященный этой теме.
Мы уже упоминали о некоторых крайностях того, почему нам нужно защищать наши данные, но ниже перечислены еще несколько:
Это позволяет мне рассказать о методологии 3-2-1. Моя первая копия или резервная копия данных должна быть как можно ближе к моей производственной системе, причина этого заключается в скорости восстановления и, опять же, возвращаясь к исходному пункту о случайном удалении, это будет наиболее распространенной причиной для восстановления. Но я хочу хранить эти данные на подходящем втором носителе за пределами исходной или рабочей системы.
Затем мы хотим убедиться, что мы также отправляем копию наших данных на внешний носитель или за пределы системы, и здесь нам на помощь приходит второе место, будь то другой дом, здание, центр обработки данных или публичное облако.
Мы, скорее всего, слышали все мифы о том, что резервное копирование не нужно, например, такие как “Все не имеет состояния”. Если все не имеет состояния, то что тогда бизнес? Нет баз данных? документов? Очевидно, что каждый человек в компании несет определенную ответственность за обеспечение своей защиты, но, скорее всего, именно операционные команды должны обеспечить процесс резервного копирования критически важных приложений и данных.
Еще одна хорошая фраза: “Высокая доступность - это моя резервная копия, мы встроили несколько узлов в наш кластер, поэтому он ни за что не выйдет из строя!”, кроме тех случаев, когда вы допускаете ошибку в базе данных, и она реплицируется на все узлы кластера, или когда происходит пожар, наводнение, что означает, что кластер больше недоступен, а вместе с ним и важные данные. Речь идет не об упрямстве, а о том, чтобы быть в курсе данных и сервисов, абсолютно все должны учитывать высокую доступность и отказоустойчивость в своей архитектуре, но это не заменяет необходимости резервного копирования!
Репликация также может дать нам копию данных вне офиса, и, возможно, упомянутый выше кластер действительно живет в нескольких местах, однако первая случайная ошибка все равно будет реплицирована туда. Но, опять же, требование резервного копирования должно стоять в одном ряду с репликацией приложений или системной репликацией в среде.
Теперь, учитывая все вышесказанное, можно впасть в крайность и отправить копии данных в слишком большое количество мест, что приведет не только к большим затратам, но и к увеличению риска подвергнуться атаке, поскольку площадь вашей поверхности теперь значительно увеличилась.
В любом случае, кто заботится о резервном копировании? В каждом предприятии это будет по-разному, но кто-то должен понимать требования к резервному копированию. Но также необходимо понимать план восстановления!
Никому нет дела, пока всем нет дела
Резервное копирование является ярким примером: никто не заботится о резервном копировании, пока вам не понадобится что-то восстановить. Наряду с требованием резервного копирования данных нам также необходимо подумать о том, как мы будем восстанавливать данные!
В нашем примере с текстовыми документами речь идет об очень маленьких файлах, поэтому возможность копирования туда и обратно является простой и быстрой. Но если речь идет о файлах размером более 100 ГБ, то на это потребуется время. Также необходимо учитывать уровень, на котором требуется восстановление, например, если мы возьмем виртуальную машину.
У нас есть вся виртуальная машина, у нас есть операционная система, установка приложений, а если это сервер баз данных, то у нас есть и некоторые файлы баз данных. Если мы допустили ошибку и вставили неправильную строку кода в нашу базу данных, мне, вероятно, не нужно восстанавливать всю виртуальную машину, я хочу быть детальным в том, что я восстанавливаю.
Сценарий резервного копирования
Теперь я хочу начать строить скрипт защиты некоторых данных, в частности, я хочу защитить некоторые файлы на моей локальной машине (в данном случае Windows, но инструмент, который я собираюсь использовать, на самом деле не только бесплатный и с открытым исходным кодом, но и кроссплатформенный). Я хочу убедиться, что они защищены на устройстве NAS, которое у меня есть дома, а также в облачном хранилище Object Storage bucket.
Я хочу сделать резервную копию этих важных данных, так получилось, что это репозиторий для 90DaysOfDevOps, который, да, также отправляется на GitHub, где вы, вероятно, сейчас это читаете, но что, если моя машина умрет, а GitHub будет закрыт? Как бы кто-нибудь смог прочитать содержимое, а также как бы я мог восстановить эти данные на другом сервисе.
Существует множество инструментов, которые могут помочь нам достичь этого, но я собираюсь использовать инструмент под названием Kopia - это инструмент резервного копирования с открытым исходным кодом, который позволит нам шифровать, дедупировать и сжимать наши резервные копии, а также отправлять их во многие места.
Вы найдете релизы для загрузки здесь на момент написания статьи я буду использовать версию 0.10.6.
Установка Kopia
Существует Kopia CLI и GUI, мы будем использовать GUI, но знайте, что вы можете иметь и CLI версию для тех Linux серверов, которые не дают вам GUI.
Я буду использовать KopiaUI-Setup-0.10.6.exe.
Действительно быстрая установка, а затем, когда вы откроете приложение, вам предложат выбрать тип хранилища, которое вы хотите использовать в качестве хранилища резервных копий.
Настройка хранилища
Сначала мы хотим создать хранилище на локальном NAS-устройстве и собираемся сделать это с помощью SMB, но можно использовать и NFS.
На следующем экране мы собираемся определить пароль, этот пароль используется для шифрования содержимого хранилища.
Теперь, когда хранилище настроено, мы можем запустить adhoc snapshot, чтобы начать запись данных в хранилище. [18:26, 16.06.2022] evgschegolkova:
Прежде всего, нам нужно ввести путь к тому, что мы хотим сделать снимок, и в нашем случае мы хотим сделать копию папки 90DaysOfDevOps. Вскоре мы вернемся к аспекту планирования.
Мы можем определить хранение наших снимков.
Возможно, есть файлы или типы файлов, которые мы хотим исключить.
Если бы мы хотели определить расписание, мы могли бы сделать это на следующем экране, когда вы впервые создаете этот снимок, это начальная страница для определения.
И вы увидите ряд других настроек, которые могут быть обработаны здесь.
Выберите snapshot now, и данные будут записаны в ваше хранилище.
Внесетевое резервное копирование на S3
С помощью Kopia мы можем настроить только одно хранилище одновременно. Но через пользовательский интерфейс мы можем проявить творческий подход и, по сути, иметь несколько файлов конфигурации хранилища на выбор для достижения нашей цели - иметь локальную и внесетевую копию в Object Storage.
Хранилище Object Storage, в которое я решил отправить свои данные, будет Google Cloud Storage. Сначала я вошел в свой аккаунт Google Cloud Platform и создал себе ведро хранения. В моей системе уже был установлен Google Cloud SDK, но выполнение команды gcloud auth application-default login позволило мне аутентифицироваться в моей учетной записи.
Затем я использовал CLI Kopia, чтобы показать мне текущее состояние моего хранилища после того, как мы добавили наше SMB хранилище в предыдущих шагах. Я сделал это с помощью команды "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status.
Теперь мы готовы заменить конфигурацию хранилища для целей демонстрации. Если бы мы хотели получить долгосрочное решение для обоих хранилищ, мы бы создали файл smb.config и файл object.config и могли бы запускать обе эти команды для отправки наших копий данных в каждое место. Для добавления нашего хранилища мы выполнили команду "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository create gcs --bucket 90daysofdevops.
Приведенная выше команда учитывает, что ведро Google Cloud Storage, которое мы создали, называется 90daysofdevops.
Теперь, когда мы создали наше новое хранилище, мы можем снова запустит [18:27, 16.06.2022] evgschegolkova:
Прежде всего, нам нужно ввести путь к тому, что мы хотим сделать снимок, и в нашем случае мы хотим сделать копию папки 90DaysOfDevOps. Вскоре мы вернемся к аспекту планирования.
Мы можем определить хранение наших снимков.
Возможно, есть файлы или типы файлов, которые мы хотим исключить.
Если бы мы хотели определить расписание, мы могли бы сделать это на следующем экране, когда вы впервые создаете этот снимок, это начальная страница для определения.
И вы увидите ряд других настроек, которые могут быть обработаны здесь.
Выберите snapshot now, и данные будут записаны в ваше хранилище.
Внесетевое резервное копирование на S3
С помощью Kopia мы можем настроить только одно хранилище одновременно. Но через пользовательский интерфейс мы можем проявить творческий подход и, по сути, иметь несколько файлов конфигурации хранилища на выбор для достижения нашей цели - иметь локальную и внесетевую копию в Object Storage.
Хранилище Object Storage, в которое я решил отправить свои данные, будет Google Cloud Storage. Сначала я вошел в свой аккаунт Google Cloud Platform и создал себе ведро хранения. В моей системе уже был установлен Google Cloud SDK, но выполнение команды gcloud auth application-default login позволило мне аутентифицироваться в моей учетной записи.
Затем я использовал CLI Kopia, чтобы показать мне текущее состояние моего хранилища после того, как мы добавили наше SMB хранилище в предыдущих шагах. Я сделал это с помощью команды "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status.
Теперь мы готовы заменить конфигурацию хранилища для целей демонстрации. Если бы мы хотели получить долгосрочное решение для обоих хранилищ, мы бы создали файл smb.config и файл object.config и могли бы запускать обе эти команды для отправки наших копий данных в каждое место. Для добавления нашего хранилища мы выполнили команду "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository create gcs --bucket 90daysofdevops.
Приведенная выше команда учитывает, что ведро Google Cloud Storage, которое мы создали, называется 90daysofdevops.
Теперь, когда мы создали наше новое хранилище, мы можем снова запустить команду "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status, которая теперь покажет конфигурацию хранилища GCS.
Следующее, что нам нужно сделать, это создать снимок и отправить его в наш только что созданный репозиторий. Используя команду "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config kopia snapshot create "C:\Users\micha\demo\90DaysOfDevOps" мы можем запустить этот процесс. В браузере ниже вы можете увидеть, что в нашем ведре Google Cloud Storage теперь есть файлы kopia, основанные на нашей резервной копии.
С помощью вышеописанного процесса мы смогли решить нашу задачу по отправке важных данных в 2 разных места, одно из которых находится вне помещения в Google Cloud Storage, и, конечно же, у нас все еще есть наша производственная копия данных на другом типе носителя.
Восстановление
Восстановление - это еще один важный момент, Kopia дает нам возможность не только восстанавливать данные в существующее местоположение, но и в новое.
Если мы выполним команду "C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config snapshot list, это приведет к списку снимков, которые в настоящее время находятся в нашем настроенном хранилище (GCS).
Затем мы можем смонтировать эти снимки непосредственно из GCS, используя команду ``C:\Program Files\KopiaUI\resources\server\kopia.exe’’ –config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config mount all Z:`.
Мы также можем восстановить содержимое снимка с помощью команды kopia snapshot restore kdbd9dff738996cfe7bcf99b45314e193.
Очевидно, что приведенные выше команды очень длинные, и это потому, что я использовал KopiaUI версию kopia.exe, как объяснялось в верхней части руководства, вы можете скачать kopia.exe и поместить в путь, чтобы вы могли просто использовать команду kopia.
На следующем занятии мы сосредоточимся на защите рабочих нагрузок в Kubernetes.