Handy backup for cloud

Cloud server backup is a modern method of data keeping for enterprise and individual users, providing both offsite data storage and mobility for restoring the information. Handy Backup is a good example of enterprise cloud backup software, supporting any modern storage for Windows server cloud backup.

Sample Cloud Server Solutions for Enterprise Cloud Backup

Google Drive Backup

Perhaps one of most known cloud backup solutions, Google Drive allows storing data of any type to an expandable cloud account with a very reasonable price for a free space. Readily available and with many internal utilities for data processing, Google Drive is a true part of the modern IT giant!

• The dedicated Google Drive plug-in connects Handy Backup to Google Drive by using its own API to manage data exchange with this cloud backup server.

Dropbox Backup

The popular data-sharing and cloud storage solution, Dropbox can contain and synchronize thousands of files and folders. Like Google Drive, it provides file-storing and cloud backup services primarily to home users and small business owners, and has utilities to complement file storing and sharing.

• For Handy Backup, the API-driven Dropbox plug-in governs all cloud server backup operations related to Dropbox.

OneDrive Backup

Designed as the standard cloud server for Windows users, including Windows server cloud backup, the OneDrive is the cheap, secure, fast and capable method of storing any data, from common files and folders to big enterprise data arrays (if you need it). It can also store Windows images.

• Handy Backup provides the dedicated OneDrive plug-in based on the own API for this cloud server solution.

Other Popular Cloud Backup Service Options

Besides cloud server solutions and the related plug-ins described before, Handy Backup contains some other plug-ins for accessing many other cloud servers existed. The list of these plug-ins includes Box, 4shared, Xref for AutoCAD, BackBlaze and some other cloud server backup solutions.

• Updates for Handy Backup constantly expand the quantity of supported clouds. Please check for upgrades (free for owners!) to find new cloud server backup plug-ins!

Dedicated Cloud Based Backup Services

Amazon S3 Backup

The dedicated cloud server backup solution for enterprise-level data, Amazon S3 provides both high security of transferring and storing the information via the cloud API and a good productivity for making "hot" copies of relatively big datasets, such as databases, dynamic website content and other clouds.

• Handy Backup provides the Amazon S3 plug-in for accessing accounts (buckets) on this cloud server, with extended an authorization procedure supporting the AWS4 protocol.

HBDrive Backup

In addition to the vast list of cloud server backup plug-ins, Handy Backup has its own backup storage vault. Protected from physical and malware perils, this vault called HBDrive combines best features of cloud server and FTP storage, including protected data transferring.

• All editions of Handy Backup contain the dedicated Online Backup plug-in, making backup to cloud and data restoring from the HBDrive cloud storage service.

Get a free 5 GB secured storage space!

Other Private and Commercial Cloud Backup Servers

You can also organize backup to a cloud of any type, from a local cloud server raised on a small home NAS to an enterprise-level private service to some enterprise cloud backup solution that not yet have its own plug-in in Handy Backup. All you need is to have a WebDAV interface or bridge for that cloud, or the S3 protocol for data transfer between a cloud and other devices.

• The WebDAV multi-cloud plug-in governs all operations when you back up to cloud using the WebDAV protocol, as the S3 Cloud plug-in supports S3 connections, such as Wasabi backup.

Note: When using any cloud plug-in as a backup source on the Step 2 of a task wizard, you can locate any cloud plug-in in the "Cloud" section on the left panel. When making backup to cloud, you can select each available cloud server plug-in from the open list on the Step 3.

Recommended Solution

Version 8.0.6 , built on 2 October, 2019 . 105 MB
Backup Software from Novosoft LLC. 249 USD per license.

Handy Backup Small Server

The ultimate backup solution for one machine, the Small Server edition has a capability to use any available cloud server just out of the box!

Version 8.0.6 , built on 2 October, 2019. 105 MB
Backup Software from Novosoft LLC. 299 USD per license.

Handy Backup Server Network

The Server Network edition can organize centralized backup and restoration for a local network of any complexity, including managing data in any enterprise cloud backup tasks!

Other Crucial Advantages of Handy Backup

Besides the vast selection of cloud server backup options, Handy Backup has some other important features for organizing the entire job:

• Scheduling tasks to run at an exact time, with a period from a minute to some months, or by some system event.
• Data encryption and compression options, built into the program, to enhance protection and wholeness of an archive.
• Keeping data in native formats, allowing browsing, viewing or even modifying files just from a cloud server, without restoring.
• Partition backup options (incremental, differential and mixed backup) to reduce the size of data archive for keeping on a cloud server backup.
• "Hot" backup for most data types available.

Version 8.0.6, built on 2 October, 2019
105 MB

Try Handy Backup as your trusted software for backup to a cloud server of your choice! Download and install the free 30-day trial version of Handy Backup with all cloud server plug-ins and program features available for you!

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

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

Считается, что история правила бэкапа «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. И да, Яндекс.Диск в списке. Конфигурация до недавнего времени производилась только через интерактивное консольное меню, но относительно недавно появилась возможность запускать веб-интерфейс и настраивать через него.

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

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

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

В принципе, как уже полноценное решение для резервного копирования, rclone можно использовать вместе с Duplicati, выбрав rclonе как тип хранилища. Тогда Duplicati будет создавать резервные копии с использованием vss (снапшотов) по планировщику, а первое будет отвечать за загрузку резервных копий в нужное нам облако. Конечно, можно использовать и любое другое решение вроде Cobian или вовсе делать снапшоты vss командой diskshadow, архивировать и заливать в облако при помощи rclone. Правда, если совсем уж изобретать велосипед, то и никакой rclone не нужен.

Конечно, если облачный провайдер предоставляет доступ по WebDAV, загрузка данных будет простой. Пример для cmd и Яндекс.Диска:

Но не все провайдеры умеют в WebDAV, и есть вопросы по скорости и стабильности работы. Поэтому можно использовать API, если, конечно, провайдер предоставляет такой доступ. Разберем пример с тем же Яндексом.

Для авторизации Яндекс использует OAuth, поэтому для нашего скрипта понадобится завести специальный токен. Сначала нужно создать приложение в разделе «Создание приложения» на сайте.

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

Доступ скрипта к API Яндекс.Диска.

И подставить URL для разработки в Callback URI (будет доступен после установки галочки «Веб-сервисы» на доступных платформах):

Настройка Callback URI.

После получения ID приложения следует перейти по ссылке:

Где 12345678 — полученный ID. После предоставления приложению доступа мы получим желанный OAuth-токен, который уже можно применять в скриптах. Вот, например, загрузка файла на Яндекс.Диск при помощи PowerShell:

Организовать ротацию файлов, контроль загрузки и прочий «обвес» предлагается самостоятельно, благо API Яндекса хорошо документировано. Но лично я предпочитаю не изобретать велосипед, а использовать rclone.

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

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

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

Началось все с того, что нужен был быстрый бэкап MySQL по расписанию, а именно каждый день. Так как это нужно было сделать сегодня на вчера был выбран уже установленный софт — Handy Backup. Быстренько сделав задачу на бэкап и настроив уведомления я забыл об этом на полгода.
Это было моей первой ошибкой, потому что

«Когда дела идут хорошо, что-то должно случиться в самом ближайшем будущем».

Файлы базы, которую я бэкапил хранились в «неубиваемом» хранилище производства HP. Мои бэкапы складывались туда же и переодически сохранялись еще и на ленту. Казалось бы, все надежно. Но ведь все забыли, что еще один закон действует безотказно

«Из всех неприятностей произойдет именно та, ущерб от которой больше».

И вот хваленое хранилище производства HP в одночасье рухнуло, похоронив под обломками несчастную базенку, а заодно и все мои бэкапы. Потратив два дня только на то, чтобы узнать, что HP не намеряна восстанавливать хранилище в ближайшее время (возможно, никто просто не знает как восстановить то, что нельзя убить), было принято решение поднять последний бэкап с ленты. Оказалось, он был сделан буквально вчера. Казалось, можно вздохнуть с облегчением, но

«Если вам кажется, что ситуация улучшается, значит вы чего-то не заметили».

И правда, заглянув в файлы бэкапа я обнаружил, что там полно вопросиков! Чорт! Ну конечно база была в юникоде, про другие кодировки уже наверно и не знает никто. Мало того Handy Backup как-то кодирует бэкапы и там нет простого SQL.
Выругав себя за то, что не проверил такую простую вещь раньше, я подумал: «Хер с ним, восстановлю как есть, напишу скрипт который обновит вопросики данными из другой таблицы, где все было в закодированном виде», но черт бы побрал эти законы

«Если какая-нибудь неприятность может произойти, она случится».

Оказалось, что Handy Backup при восстановлении полностью заменял структуру таблиц, напрочь игнорируя типы полей, ключи и все остальное. Если таблица уже существовала, он ее удалял и создавал свою. В итоге я получил таблицы где были только int и varchar(255) поля. Надо ли объяснять, что все что было длиннее 255 символов просто обрезалось.
Перепробовав все версии Handy Backup и возможные настройки ODBC я был на грани отчаянья. Была ночь и я, без надежды на успех, написал в аську супорту Novosoft, который делает Handy Backup. Ответа не последовало. Меня это не удивило, я имел дело с разными компаниями и неотзывчивая техподдержка была обычным делом. Предчувствуя как мою *опу завтра будут рвать на британский флаг, я пошел спать.

«Всякая работа требует больше времени, чем вы думаете».

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

«Все не так легко, как кажется».

Получив новую инъекцию адреналина от возможности восстановить базу, я заменил dll и… ничего. Совсем ничего не изменилось. Лихорадочно пробуя разные варианты запуска програмы, я начал понимать, что не продвинулся за сутки ни на шаг. Мозг требовал сна, совесть — решения проблемы. И решение пришло. Пришло последним, как всегда приходят правильные решения. Я включил логирование запросов MySQL и, прогнав полное восстановление через Handy Backup, собрал 3 гигабайта запросов на вставку данных.
Через час база была восстановлена.

Осталось исправить вопросики, но это уже совсем другая история.

«Есть моменты, когда все удается. Не ужасайтесь, это пройдет».

Надеюсь, мой опыт поможет кому-то не попасть в похожую переделку. Проверьте свои бэкапы. Проверьте программы, которые их делают. Проверьте хранилища, где хранятся бэкапы.