Сегодня мне хотелось бы еще раз пройтись по набившему оскомину резервному копированию в облако. Рассуждать на тему хорошо это или плохо, я не буду, но хочу поделиться примерами реализаций решений для этого самого облачного резервного копирования — от готового ПО до костылей на велосипедах.
Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.
3-2-1, поехали
Считается, что история правила бэкапа «3-2-1» начинается с Питера Крога (Peter Krogh), который изложил его в книге «Управление цифровыми активами для фотографов». Вкратце напомню этот принцип:
- Копий данных должно быть минимум 3.
- Как минимум 2 копии должны быть на физических носителях разного типа. Например, одна копия — рабочие данные на дисковом массиве, вторая копия — данные на магнитной ленте.
- Как минимум одна резервная копия должна хранится не в офисе.
Лично я чаще всего использую чуть другие правила в формировании резервных копий.
Классическая схема «3-2-1».
Во-первых, в качестве изначальных данных я беру резервные копии, а во-вторых, не всегда удобно и бюджетно хранить их на носителях различного типа — особенно для малого и среднего бизнеса. Моя обычная стратегия хранения резервных копий такова:
- Оперативные резервные копии. Основная их цель — в случае небольшого сбоя обеспечить максимально быстрое восстановление. В зависимости от инфраструктуры храниться эти резервные копии могут даже на копируемом сервере — только на отдельном диске.
- Архивные резервные копии. Они хранятся уже обязательно как минимум на другом сервере и с историей (чаще всего — 6 ежедневных резервных копий, 4 еженедельных и 4 ежеквартальных).
- Удаленные резервные копии. Резервные копии хранятся обязательно в другом месте — на сервере в удаленном ЦОД или в облаке. Неплохой вариант — по возможности синхронизировать с удаленным хранилищем каталог архивных резервных копий.
С оперативными и архивными резервными копиями обычно все достаточно просто, разве что следует придерживаться определенных рекомендаций. Один из вариантов таких рекомендаций — под спойлером.
- Сервер с резервными копиями по-хорошему должен быть так или иначе изолирован от рабочей сети на случай, если вдруг заведется шифровальщик.
- Неплохой вариант, когда сервер забирает резервные копии, а не получает их — на случай компрометации архивируемого сервера.
- История архивов — must have. Часто встречал инфраструктуры, где хранилась только одна резервная копия важных данных, и в случае атаки шифровальщика или потери данных «позавчера», данные в резервной копии были уже испорчены или не те, что нужно.
- Не забываем копировать не только данные, но и операционную систему.
- Теневые копии и прочие снапшоты — это очень хорошо и здорово, но это не резервное копирование. Можно их использовать как замену оперативным резервным копиям, но лучше совмещать.
- Архивы с расширением .exe или .dll — неплохой вариант обмануть так-себе-шифровальщика.
- RAID — это совсем не про резервное копирование. Совсем-совсем.
А вот с удаленными резервными копиями вопросов много. В частности, надо выбирать, где хранить эти самые копии и чем их туда забрасывать. Сначала приведу несколько примеров «где».
Выбираем уютное облако
Одним из вариантов будет простая и незамысловатая аренда выделенного сервера или установка своего сервера в ЦОД на колокейшн.
Действительно, «облако», которое построил сам, дает больше контроля над происходящим, да и выбор решения для хранения и непосредственно резервного копирования остается на усмотрение системного администратора. Можно даже сервер включить в домен «на земле», как я описывал в статье «Как я базы 1С в Германии прятал».
С другой стороны, контроль означает и ответственность — необходимо будет мониторить состояние сервера на случай аппаратных и программных проблем, при этом недостаток облаков в виде зависимости от интернета и вопроса доверия сторонним людям никто не отменял.
А не ваш ли это арендованный сервер у недорогого хостера?
Другим вариантом будет использование специализированных сервисов, которые создавались как раз для хранения резервных копий. Самым известным примером являются сервисы Amazon Glacier. Они окутаны легендами на тему используемых технологий — начиная от ленточных кассет и заканчивая blu ray-дисками и робо-руками. Но официально это недорогие HDD.
В отличие от арендованного сервера, решение уже начинает пахнуть кровавым энтерпрайзом со многими «девятками надежности» после запятой. Правда, как и многое у веб-сервисов Amazon, он обладает непростой формулой расчета стоимости. Если грубо упрощать, то загрузка данных на сервис — бесплатна, хранение — совсем недорогое ($1 за 1 Тб в месяц), а вот за получение данных придется заплатить. Как на старых ярмарках — «вход бесплатный, выход 15 копеек».
Классические сервисы хранения данных вроде Amazon S3 и Yandex Object Storage тоже, конечно, можно использовать для резервных копий, но ценник в таком случае будет менее гуманный — ~$10мес за 1 ТБ у Яндекса. Также нельзя не упомянуть решения вида «все включено» от производителей систем резервного копирования, благо своего облака сейчас нет только у ленивого. Например, Acronis Cloud Storage как дополнение к продуктам Acronis буквально за $299 в год даст 250 Гб на своих серверах.
Третьим вариантом будет использование облачных хранилищ, которые не очень предназначены для хранения резервных копий компании, а больше ориентированы на простых пользователей. Приведу лишь несколько из них, которые на слуху:
Я сейчас не буду сравнивать облачные платформы, отдам это на откуп многочисленным материалам в сети. Например, статье «Облачные хранилища для физических лиц: что выбрать и почему». Лично я для своих нужд остановился на Яндекс.Диске, потому что он один из немногих, кто на бесплатных планах умеет WebDAV, API и снапшоты (историю) файлов на диске. Ну и, конечно, у меня скопилось некоторое количество бесплатных гигабайтов на нем.
Конечно, при выборе стоит обращать внимание не только на бесплатное количество и стоимость гигабайтов, но и на лицензионное соглашение, поскольку резервное копирование условных баз 1С может его нарушать. Отдельно стоит отметить пункты, по которым облачный провайдер не несет никакой ответственности, может в любой момент удалить все файлы и ничего ему за это не будет. Зато практически у всех таких сервисов есть ПО, которое позволяет загружать файлы на сервис, что подводит нас к следующему пункту сегодняшнего повествования.
Чем грузить на уютное облако
Лично мне ПО, предоставленное сервисами, не очень нравится использовать (если, конечно, речь не про специализированный сервис вроде Acronis): не всегда есть возможность настроить расписание синхронизации, да и еще жива в памяти история, когда Яндекс.Диск при обновлении устраивал патч Бармина операционной системе. По счастью, существуют специальные ПО, поддерживающие различных провайдеров. Как обычно, приведу несколько примеров в основном бесплатных и околобесплатных решений.
Handy Backup. Выдается на первой странице гугла по запросу «резервное копирование в облако». Есть платные версии различного функционала, отдельные плагины (например, для Exchange и 1C). Есть даже свое облако — HBDrive. Но самое главное, пока еще есть бесплатная версия, которая умеет бэкапить только в облако — Handy Backup Free for Cloud. К сожалению, в рамках тестирования мне не удалось заставить ее стабильно работать с Яндекс.Диском — периодически назначенное задание не срабатывало. Сложно что-то хотеть от бесплатного решения, но от использования этого ПО я отказался.
CloudBerry Backup. Всем хорош продукт, есть даже решения для восстановления отдельных объектов Exchange, есть поддержка множества разных провайдеров. От использования остановило отсутствие бесплатной версии и поддержки обычного Яндекс.Диска, только S3 совместимое хранилище Yandex Object Storage.
Список поддерживаемых провайдеров решения от CloudBerry Lab.
Duplicati 2. Уже совсем бесплатный продукт, даже для коммерческого использования. Есть под все популярные платформы от Windows до GNULinux, работать можно как через веб-интерфейс, так и через командную строку, также есть и шифрование бэкапов «из коробки».
Интерфейс Duplicati, поддерживаемые провайдеры.
К сожалению, «из коробки» Яндекс.Диск не поддерживается — только в режиме WebDAV. В этом режиме решение от Яндекса работает не идеально — бывают проблемы с крупными файлами. Но в списке допустимого назначения существует один, который решает эту проблему. Вот же он.
Rclone. Пожалуй, это мой бесспорный лидер среди прочего ПО. Утилита командной строки под множество платформ, на официальном сайте доступна загрузка в том числе и под редкие операционные системы вроде Plan9 и Solaris. Список поддерживаемых облачных провайдеров тоже впечатляет — в нем есть поддержка даже Cephs и OwnCloud. И да, Яндекс.Диск в списке. Конфигурация до недавнего времени производилась только через интерактивное консольное меню, но относительно недавно появилась возможность запускать веб-интерфейс и настраивать через него.
Веб-интерфейс rclone.
К минусам стоит отнести отсутствие каких-либо встроенных планировщиков. Утилита работает исключительно как транспорт нас облаков, зато и не требует установки. В том числе и из-за этого я ее использую в связке с Яндекс.Диском для переноса информации с одних удаленных серверов на другие — оказалось, что крупные файлы быстрее закинуть на облако и скачать с облака, чем организовывать прямой файлообмен. Да и подгружать резервные копии одно удовольствие. Например, чтобы скопировать в облако только свежие файлы, можно использовать команду:
rclone copy --max-age 24h --no-traverse D:backups yandex:backups
Где yandex — имя конфига, созданного заранее, а backups — папка с бэкапами.
Более подробно принципы работы rclone разобраны в официальной документации и в статье «Rclone: rsync для облаков».
В принципе, как уже полноценное решение для резервного копирования, rclone можно использовать вместе с Duplicati, выбрав rclonе как тип хранилища. Тогда Duplicati будет создавать резервные копии с использованием vss (снапшотов) по планировщику, а первое будет отвечать за загрузку резервных копий в нужное нам облако. Конечно, можно использовать и любое другое решение вроде Cobian или вовсе делать снапшоты vss командой diskshadow, архивировать и заливать в облако при помощи rclone. Правда, если совсем уж изобретать велосипед, то и никакой rclone не нужен.
Создаем свой велосипедо-скрипт
Конечно, если облачный провайдер предоставляет доступ по WebDAV, загрузка данных будет простой. Пример для cmd и Яндекс.Диска:
net use Z: "https://webdav.yandex.ru/backup/" /User:login@yandex.ru password
rem копируем файлы любым способом
net use Z: /delete
Но не все провайдеры умеют в WebDAV, и есть вопросы по скорости и стабильности работы. Поэтому можно использовать API, если, конечно, провайдер предоставляет такой доступ. Разберем пример с тем же Яндексом.
Для авторизации Яндекс использует OAuth, поэтому для нашего скрипта понадобится завести специальный токен. Сначала нужно создать приложение в разделе «Создание приложения» на сайте.
Нужно не забыть дать доступ приложению на Яндекс.Диске:
Доступ скрипта к API Яндекс.Диска.
И подставить URL для разработки в Callback URI (будет доступен после установки галочки «Веб-сервисы» на доступных платформах):
Настройка Callback URI.
После получения ID приложения следует перейти по ссылке:
https://oauth.yandex.ru/authorize?response_type=token&client_id=12345678&display=popupГде 12345678 — полученный ID. После предоставления приложению доступа мы получим желанный OAuth-токен, который уже можно применять в скриптах. Вот, например, загрузка файла на Яндекс.Диск при помощи PowerShell:
#путь к файлу
$filepath = "D:backup.zip"
$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Authorization" ,'OAuth НашOauthТокен')
$headers.Add("Content-Type","application/json")
#получаем от Яндекса URL для загрузки файла
$UploadUrl= (Invoke-RestMethod -method GET -URI ("https://cloud-api.yandex.net:443/v1/disk/resources/upload?path=backup.zip") -Headers $headers).href
#загружаем сам файл
Invoke-WebRequest -uri $UploadUrl -Method Put -Infile $filepath -ContentType 'application/zip'
Организовать ротацию файлов, контроль загрузки и прочий «обвес» предлагается самостоятельно, благо API Яндекса хорошо документировано. Но лично я предпочитаю не изобретать велосипед, а использовать rclone.
Ну и при резервном копировании в облако я настоятельно рекомендую шифровать архивы, чтоб не оказаться в ситуации как герой стихотворения известного в определенных кругах поэта Айклауда Фон Браузера, строкой которого и названа эта статья.
В комментариях предлагаю не разводить холивар на тему рациональности облачного резервного копирования, а поделится своим любимым инструментом бэкапа.
Автор: Tri-Edge
