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

Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.

3-2-1, поехали

Считается, что история правила бэкапа «3-2-1» начинается с Питера Крога (Peter Krogh), который изложил его в книге «Управление цифровыми активами для фотографов». Вкратце напомню этот принцип:

• Копий данных должно быть минимум 3.
• Как минимум 2 копии должны быть на физических носителях разного типа. Например, одна копия — рабочие данные на дисковом массиве, вторая копия — данные на магнитной ленте.
• Как минимум одна резервная копия должна хранится не в офисе.

Лично я чаще всего использую чуть другие правила в формировании резервных копий.

Классическая схема «3-2-1».

Во-первых, в качестве изначальных данных я беру резервные копии, а во-вторых, не всегда удобно и бюджетно хранить их на носителях различного типа — особенно для малого и среднего бизнеса. Моя обычная стратегия хранения резервных копий такова:

• Оперативные резервные копии. Основная их цель — в случае небольшого сбоя обеспечить максимально быстрое восстановление. В зависимости от инфраструктуры храниться эти резервные копии могут даже на копируемом сервере — только на отдельном диске.
• Архивные резервные копии. Они хранятся уже обязательно как минимум на другом сервере и с историей (чаще всего — 6 ежедневных резервных копий, 4 еженедельных и 4 ежеквартальных).
• Удаленные резервные копии. Резервные копии хранятся обязательно в другом месте — на сервере в удаленном ЦОД или в облаке. Неплохой вариант — по возможности синхронизировать с удаленным хранилищем каталог архивных резервных копий.

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

А вот с удаленными резервными копиями вопросов много. В частности, надо выбирать, где хранить эти самые копии и чем их туда забрасывать. Сначала приведу несколько примеров «где».

Выбираем уютное облако

Одним из вариантов будет простая и незамысловатая аренда ^[1] выделенного сервера или установка своего сервера в ЦОД на колокейшн.

Действительно, «облако», которое построил сам, дает больше контроля над происходящим, да и выбор решения для хранения и непосредственно резервного копирования остается на усмотрение системного администратора. Можно даже сервер включить в домен «на земле», как я описывал в статье «Как я базы 1С в Германии прятал ^[2]».

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

А не ваш ли это арендованный сервер у недорогого хостера?

Другим вариантом будет использование специализированных сервисов, которые создавались как раз для хранения резервных копий. Самым известным примером являются сервисы Amazon Glacier ^[3]. Они окутаны легендами на тему используемых технологий — начиная от ленточных кассет и заканчивая blu ray-дисками и робо-руками. Но официально это недорогие HDD.

В отличие от арендованного сервера, решение уже начинает пахнуть кровавым энтерпрайзом со многими «девятками надежности» после запятой. Правда, как и многое у веб-сервисов Amazon, он обладает непростой формулой расчета стоимости. Если грубо упрощать, то загрузка данных на сервис — бесплатна, хранение — совсем недорогое ($1 за 1 Тб в месяц), а вот за получение данных придется заплатить. Как на старых ярмарках — «вход бесплатный, выход 15 копеек».

Классические сервисы хранения данных вроде Amazon S3 ^[4] и Yandex Object Storage ^[5] тоже, конечно, можно использовать для резервных копий, но ценник в таком случае будет менее гуманный — ~$10мес за 1 ТБ у Яндекса. Также нельзя не упомянуть решения вида «все включено» от производителей систем резервного копирования, благо своего облака сейчас нет только у ленивого. Например, Acronis Cloud Storage ^[6] как дополнение к продуктам Acronis буквально за $299 в год даст 250 Гб на своих серверах.

Третьим вариантом будет использование облачных хранилищ, которые не очень предназначены для хранения резервных копий компании, а больше ориентированы на простых пользователей. Приведу лишь несколько из них, которые на слуху:

• Dropbox ^[7].
• OneDrive ^[8].
• Google Drive ^[9].
• Mega ^[10].
• Яндекс.Диск ^[11].
• Облако Mail.Ru ^[12].

Я сейчас не буду сравнивать облачные платформы, отдам это на откуп многочисленным материалам в сети. Например, статье «Облачные хранилища для физических лиц: что выбрать и почему ^[13]». Лично я для своих нужд остановился на Яндекс.Диске, потому что он один из немногих, кто на бесплатных планах умеет WebDAV, API и снапшоты (историю) файлов на диске. Ну и, конечно, у меня скопилось некоторое количество бесплатных гигабайтов на нем.

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

Чем грузить на уютное облако

Лично мне ПО, предоставленное сервисами, не очень нравится использовать (если, конечно, речь не про специализированный сервис вроде Acronis): не всегда есть возможность настроить расписание синхронизации, да и еще жива в памяти история ^[14], когда Яндекс.Диск при обновлении устраивал патч Бармина ^[15] операционной системе. По счастью, существуют специальные ПО, поддерживающие различных провайдеров. Как обычно, приведу несколько примеров в основном бесплатных и околобесплатных решений.

Handy Backup. Выдается на первой странице гугла по запросу «резервное копирование в облако». Есть платные версии различного функционала, отдельные плагины (например, для Exchange и 1C). Есть даже свое облако — HBDrive ^[16]. Но самое главное, пока еще есть бесплатная версия, которая умеет бэкапить только в облако — Handy Backup Free for Cloud ^[17]. К сожалению, в рамках тестирования мне не удалось заставить ее стабильно работать с Яндекс.Диском — периодически назначенное задание не срабатывало. Сложно что-то хотеть от бесплатного решения, но от использования этого ПО я отказался.

CloudBerry Backup. Всем хорош продукт ^[18], есть даже решения для восстановления отдельных объектов Exchange, есть поддержка множества разных провайдеров. От использования остановило отсутствие бесплатной версии и поддержки обычного Яндекс.Диска, только S3 совместимое хранилище Yandex Object Storage.

Список поддерживаемых провайдеров решения от CloudBerry Lab.

Duplicati 2. Уже совсем бесплатный продукт ^[19], даже для коммерческого использования. Есть под все популярные платформы от Windows до GNULinux, работать можно как через веб-интерфейс, так и через командную строку, также есть и шифрование бэкапов «из коробки».

Интерфейс Duplicati, поддерживаемые провайдеры.

К сожалению, «из коробки» Яндекс.Диск не поддерживается — только в режиме WebDAV. В этом режиме решение от Яндекса работает не идеально — бывают проблемы с крупными файлами. Но в списке допустимого назначения существует один, который решает эту проблему. Вот же он.

Rclone. Пожалуй, это мой бесспорный лидер среди прочего ПО. Утилита командной строки под множество платформ, на официальном сайте ^[20] доступна загрузка в том числе и под редкие операционные системы вроде Plan9 и Solaris. Список поддерживаемых облачных провайдеров тоже впечатляет — в нем есть поддержка даже Cephs ^[21] и OwnCloud ^[22]. И да, Яндекс.Диск в списке. Конфигурация до недавнего времени производилась только через интерактивное консольное меню, но относительно недавно появилась возможность запускать веб-интерфейс и настраивать через него.

Веб-интерфейс rclone.

К минусам стоит отнести отсутствие каких-либо встроенных планировщиков. Утилита работает исключительно как транспорт нас облаков, зато и не требует установки. В том числе и из-за этого я ее использую в связке с Яндекс.Диском для переноса информации с одних удаленных серверов на другие — оказалось, что крупные файлы быстрее закинуть на облако и скачать с облака, чем организовывать прямой файлообмен. Да и подгружать резервные копии одно удовольствие. Например, чтобы скопировать в облако только свежие файлы, можно использовать команду:

rclone copy --max-age 24h --no-traverse D:backups yandex:backups

Где yandex — имя конфига, созданного заранее, а backups — папка с бэкапами.

Более подробно принципы работы rclone разобраны в официальной документации ^[23] и в статье «Rclone: rsync для облаков ^[24]».

В принципе, как уже полноценное решение для резервного копирования, rclone можно использовать вместе с Duplicati, выбрав rclonе как тип хранилища. Тогда Duplicati будет создавать резервные копии с использованием vss (снапшотов) по планировщику, а первое будет отвечать за загрузку резервных копий в нужное нам облако. Конечно, можно использовать и любое другое решение вроде Cobian ^[25] или вовсе делать снапшоты vss командой diskshadow ^[26], архивировать и заливать в облако при помощи 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 ^[27], поэтому для нашего скрипта понадобится завести специальный токен. Сначала нужно создать приложение в разделе «Создание приложения ^[28]» на сайте.

Нужно не забыть дать доступ приложению на Яндекс.Диске:

Доступ скрипта к 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 Яндекса хорошо документировано ^[29]. Но лично я предпочитаю не изобретать велосипед, а использовать rclone.

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

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

Автор: Tri-Edge

Источник ^[30]