back up your files to the clouds что это такое
Бекапы бывают разные. Сегодня расскажу про Acronis Backup Cloud (BaaS)
В этой статье я пошагово опишу работу сервиса резервного копирования Acronis Backup Cloud (ранее известный как «Acronis Backup as a Service»), разработанный инженерами компании Acronis. Расскажу, что представляет собой «бекапы как сервис» изнутри, и как все это работает. Перехожу непосредственно к описанию работы самого сервиса.
Как устроен сервис
Сервис состоит из серверной и клиентской части. Используются «агентная» и «безагентная» технологии, в зависимости от инфраструктуры. На клиентском компьютере или хост-сервере виртуализации устанавливается агент, задачей которого является соединение клиентского компьютера/хоста с сервером Acronis Backup Cloud и осуществление задач резервного копирования и восстановления.
Про клиентскую часть
Вот какие Агенты (Клиенты) разработаны:
Про серверную часть
Давайте рассмотрим, как устроена серверная часть. Серверная часть сервиса состоит из двух компонентов – управление системой и хранение резервных копий.
Управляющий компонент доступен через интернет и позволяет с помощью веб-браузера управлять резервным копированием удаленных машин и уже созданными резервными копиями; создавать, редактировать и удалять политики резервного копирования и политики хранения; настраивать шифрование создаваемых резервных копий, используя AES или ГОСТ стандарт, и в случае необходимости сохранять отдельные резервные копии локально; следить за состоянием удаленных машин; восстанавливать отдельные файлы/папки, диски/разделы или же целиком машины из облака прямо на «голое железо». Одной из наиболее отличительных и полезных возможностей является создание иерархии подчиненных администраторских и пользовательских учетных записей, в рамках которых распределяются доступ к данным и удаленным машинам. Администраторы могут следить за состоянием подчиненных учетных записей и в случае необходимости оказывать помощь.
Компонент хранения позволяет развернуть масштабируемое, дешевое и при этом надежное хранилище данных. Хранилище для резервных копий состоит из группы серверов, на которые записываются клиентские данные. Для обеспечения достаточного уровня надежности всех хранимых пользовательских данных каждый входящий файл разбивается на «K» блоков и затем добавляются «N-K» (где N – некоторое число большее K) блоков избыточности с использованием алгоритма коррекции ошибок Рида-Соломона. Все блоки хранятся независимо друг от друга, и сохранность любых «K» блоков из записанных «N» гарантирует восстановление хранящихся пользовательских данных.
Серверные роли
Система хранения данных Acronis строится на физических серверах. Но при этом серверные роли назначаются непосредственно дискам.
Существуют три серверные роли: Сервер Метаданных (Metadata Server (MDS)), Сервер Хранилища (Storage Server (STS)) и Front-end Server (FES).
Сервер Метаданных отвечает за хранение информации о фрагментах, на которые разбит файл, и расположение этих фрагментов на серверах. Это наиболее критический компонент системы.
Для обеспечения высокого уровня доступности и отказоустойчивости хранилища рекомендуется иметь несколько серверов с ролью MDS. Один из серверов становится основным, и метаданные периодически реплицируются с остальными серверами с ролью MDS.
Кроме того, на каждый сервер, имеющий роль MDS, также устанавливается и компонент управления системой (MGMT). В случае если основной сервер MDS перестает работать, компонент управления системой автоматически включается на другом сервере с ролью MDS, таким образом, web-консоль управления хранилищем постоянно доступна.
Сервер Хранилища (STS) предназначен для хранения фрагментов данных.
Front-End сервер позволяет клиентам сервиса Acronis Backup Cloud получать доступ к хранилищу и осуществлять передачу данных между пользовательской стороной и хранилищем данных Acronis.
Работа с сервисом
А теперь рассмотрим, как это работает на практике. Администраторам компании IT-Lite (поставщика услуги) и компаний конечных пользователей предоставляется доступ к управлению сервисом через web-консоль. На приведенной ниже диаграмме показана стандартная архитектура сервиса резервного копирования. Синие стрелки обозначают взаимодействие между компонентами программного обеспечения. Черные стрелки показывают, как администраторы и конечные пользователи получают доступ к сервису резервного копирования.
Права огласите, пожалуйста!
Администраторы IT-Lite имеют доступ к управлению группами и учетными записями пользователей.
Администраторы компаний конечных пользователей имеют права, позволяющие управлять пользователями, находящимися только в их группе! А конечные пользователи в свою очередь получают доступ к консоли, в которой можно добавлять компьютеры и создавать расписание автоматического резервного копирования. Сервис интегрирован с сайтом поставщика услуги, что позволяет пользователям сразу же по заполнению формы на этой странице проходить автоматическую регистрацию.
Acronis Backup Cloud глазами пользователя
Для конечного пользователя работа с системой проста и наглядна. После создания учетной записи пользователя и входа в Личный кабинет необходимо указать компьютер, для которого будет сконфигурировано задание на резервное копирование. Для этого нужно нажать на «+» и выбрать ОС, на которую будет установлен агент. Следующим шагом нужно сконфигурировать задание для резервного копирования.
В консоли управления пользователя отображаются все Задачи, которые выполнялись ранее для конкретного компьютера, помимо этого есть функция «Создать новую Задачу» и «Восстановить данные из облака». Кроме того, доступен просмотр текущего статуса бэкапа для заданного компьютера.
Сравнение с локальными бекапами
Данные пользователей сервиса BaaS хранятся на серверах, которые расположены в сертифицированном дата-центре класса TIER-3.
Благодаря используемой архитектуре обеспечивается защита от сбоя на уровне отдельных серверов и отдельных дисков, что, заметим, невозможно при использовании RAID-массивов, которые используются для создания отказоустойчивых хранилищ. В системе также используется полная проверка целостности данных. Уровень избыточности конфигурируется в консоли управления хранилища. Используемый при разработке хранилища самовосстанавливающийся дизайн позволяет избежать типичных для RAID-массивов потерь в производительности системы.
В случае выхода из строя одного из дисков или даже целого сервера система произведёт автоматическую перебалансировку, что позволяет избежать немедленной замены вышедших из строя компонентов.
Бэкапить локально – да, быстрее, но менее надежно
Забыл упомянуть про особенность использования бекапов как сервиса – в случае возникновения аварийной ситуации необходимо восстанавливать компьютер (виртуальную машину) целиком. Да, действительно, если сравнивать скорость восстановления сервера, то локальный бекап, конечно, сделать быстрее. Но в данном случае надо сделать выбор – либо в пользу скорости, но без гарантии от косяков, либо в пользу надежности решения, но придется немного пожертвовать скоростью.
Подытожу так – я пришла к выводу, что вопрос о надежности/простоте локальных бекапов и использования BaaS, – это, скорее, вопрос ценностный. Тот, кому информация действительно ценна, скорее выберет сервис, а остальные – первый вариант. Но это уже мое личное мнение, непосредственно к делу не относится.
Резервное копирование cloud-to-cloud: что это такое и зачем оно нужно
Входит и выходит, замечательно выходит.
Приложения, которые работают в облаке, защищены только в определенной степени. Для полной защиты данных, которые генерируются облачными приложениями, вам потребуется резервное копирование в другое облако (cloud-to-cloud backup).
По данным Forrester, расходы на услуги публичного облака вырастут к 2020 году до 236 млрд. долларов США. Это тенденция, усиливается увеличением количества приложений, размещенных в облаках.
Потреблять облачные услуги иногда настолько легко, что клиенты и ИТ-команды руководствуются принципом «работает – не трогай» и счастливы положиться в вопросах защиты данных и резервного копирования на провайдера.
Итак, почему мы видим необходимость в создании cloud-to-cloud копии?
Риски информационной безопасности в облаке
Перемещение приложений, рабочих нагрузок или ИТ-инфраструктуры в облако создает как дополнительные преимущества, так и риски. Миграция в облако означает передачу большого количества возможностей по организации хранения и защите данных третьей стороне.
Облачный сервис будет или должен иметь несколько центров обработки данных и несколько избыточных хранилищ данных для обеспечения непрерывности бизнеса и возможности восстановления данных. Он также должен обеспечивать безопасность данных на enterprise-уровне.
Но в работе облачных сервисов также возможны сбои. Они относительно редки, но ИТ-директора, которые упустили важность вопроса резервного копирования облачных данных, ставят под угрозу информационную безопасность в их организации.
Для предприятий, использующих облако, вопрос заключается не в том, не случится ли сбой в работе облачного сервиса, а в том, как и насколько успешно бизнес справится с проблемами в случае этих аварий. Хотя облачные сервисы могут обеспечить высокую степень отказоустойчивости, этого будет недостаточно для удовлетворения потребностей резервного копирования любых организаций.
Облачный vs on-premise уровень обслуживания
Облачные службы делают все возможное, чтобы поддерживать работу сервисов. Конечно, ИТ-директора должны проверить детали соглашений об уровне обслуживания (SLA). Некоторые публичные облака вовсе не гарантируют определенную доступность или время восстановления, а предлагают со своей стороны только действия «на базе наилучших усилий».
Когда дело доходит до самих данных, предприятия подвергаются еще большему риску. Провайдеры программного обеспечения как услуги (SaaS) обычно берут на себя ответственность за доступность инфраструктуры, но потеря данных является исключительно ответственностью клиента.
Это может привести к тому, что заказчики в трудную минуту останутся один на один со сложным, дорогостоящим и трудоемким восстановлением данных после сбоя.
Также провайдер облачных услуг не несет ответственности за случайное удаление данных. Человеческая ошибка — от случайной перезаписи одного поля в клиентской базе данных до очистки всего набора данных — это проблема клиента. По оценкам Backupify, провайдера резервного копирования на основе облачных технологий, одна из трех компаний теряет данные при использовании SaaS. Человеческая ошибка является наиболее распространенной причиной.
Облачные провайдеры исходя из условий договора могут также удалять данные клиентов, чья подписка на сервис закончилась. Например, Microsoft стирает все данные пользователя через 30 дней после прекращения его подписки. Если у бизнеса нет надежного плана по сбору файлов сотрудников, когда они покидают организацию, жизненно важные данные могут быть потеряны навсегда.
Опции резервного копирования в облако
В сценариях с малым масштабом пользователи могут копировать файлы, например, из Office 365 и G Suite, на локальный том или, если это разрешено правилами безопасности, на внешний диск. Но это ручной процесс, который может быть ненадежным и будет сложным для масштабирования.
Для больших файлов и более крупных приложений это редко бывает практичным. Предприятия, использующие облако по модели «инфраструктура как услуга» (IaaS) или SaaS, могут использовать процедурные интерфейсы прикладных систем (API) или стороннее программное обеспечение для резервного копирования на локальные серверы, в сетевое хранилище (NAS) или в собственный центр обработки данных.
Однако, резервное копирование данных из облачных сервисов в локальное хранилище — шаг назад. Вместо того, чтобы использовать облако, он заставляет компании сохранять или наращивать локальную инфраструктуру, увеличивая затраты и ограничивая гибкость.
Предприятия, которые создают резервные копии SaaS-приложений, будут уверены в том, что у них есть копии своих данных, но они не смогут запустить SaaS-среду внутри компании. Это ограничивает полезность локальных резервных копий. В лучшем случае бизнес столкнется с длительным восстановлением или переходом на новую платформу.
Резервное копирование данных облачных сервисов в облако может быть наилучшим вариантом.
По данным Gartner, в настоящее время только одна из 10 компаний резервирует свои данные у IaaS-провайдера. Исследователи ожидают, что этот показатель удвоится к 2020 году, так как компании осознают важность резервного копирования, и все больше провайдеров предлагают подобные облачные услуги.
Преимущества резервного копирования Cloud-to-Cloud
Резервное копирование из облака в облако обещает дать бизнесу несколько преимуществ по сравнению с локальными резервными копиями и предложениями SaaS-провайдеров, включая более низкие затраты на инфраструктуру, более быстрое резервное копирование и восстановление, а также большую гибкость.
Как и сама вычислительная мощность облачной инфраструктуры, облачные резервные копии доступны в любом месте. Организации также могут использовать резервные копии для интеллектуального анализа данных и аналитики, не подвергая исходные данные риску.
Падающие облака
К сожалению, для лиц, принимающих решения в области ИТ, рынок резервного копирования «из облака в облако» является фрагментированным и относительно незрелым. Учитывая разнообразие предлагаемых облачных вычислительных сред, службы резервного копирования значительно различаются по возможностям.
Gartner отмечает, что за последние два года поставщики услуг резервного копирования улучшили поддержку облачных сервисов, сделав проще защиту IaaS-данных и резервное копирование SaaS приложений. Наиболее развитая область в последние годы — резервное копирование ИТ-инфраструктуры как услуга – облачные копии всех виртуальных машин.
Для резервного копирования частных облаков облачный шлюз являются опцией. Частные облака используют API облачных сервисов для обеспечения резервного копирования и восстановления данных. Поставщики также предоставляют виртуализированные приложения для резервного копирования и дедупликации, которые могут выполняться в облаке.
Рынок переходит от предоставления простого «дампа базы данных» к облачному хранилищу — к более сложному, управляемому сервису, предоставляемому по модели «оплата по мере использования».
Если ваши планы проваливаются, сами планируйте возможную неудачу
Однако есть подводные камни. Резервное копирование SaaS приложений, в частности, остается сложным.
Например, резервные копии собственных данных от Salesforce.com не являются точными копиями внутренних данных приложения. Это так называемое «одностороннее» резервное копирование, которое может пропускать метаданные, а информация может быть менее «богатой», чем исходные наборы данных. Они могут быть восстановлены обратно в SaaS-приложении, но данные сначала необходимо переформатировать и перезагрузить как новые наборы данных.
В случае со многими SaaS-приложениями, если исходная услуга недоступна, у клиентов не будет возможности использовать восстановленные данные.
Резервные копии приложений, размещенных по модели IaaS, по-настоящему редко независимы от платформы. «Существует достаточно много различий между форматами данных на основных платформах, чтобы сделать восстановление весомой задачей», — предупреждает аналитик Forrester Нэвин Чхабра.
Ограничения облачных резервных копий распространяются и на персональные приложения для повышения производительности. Некоторые приложения в Office 365, в частности, трудно бэкапить. Например, Sharepoint поддерживается только несколькими поставщиками услуг резервного копирования.
Что касается резервных копий корпоративных приложений, то они должны работать как на локальной инфраструктуре, так и в публичных или частных облаках. ИТ-команды должны иметь возможность восстанавливать свои данные у любого провайдера, поддерживающего приложение, на виртуальной машине, работающей в облаке, или в локальном дата-центре. Организации должны выполнять собственную проверку бэкапов и проводить их тестирование.
На правах рекламы
Cloud4Y предоставляет несколько вариантов услуги BACKUP AS A SERVICE и Облачное хранилище. Решение Cloud4Y backup предоставляет возможность облачного резервного копирования, обеспечивающего надежность хранения любого объема данных.
Ниже перечислены три варианта реализации услуги и ко всем перечисленным вариантам предоставляется бесплатный VPN с шифрованием через Интернет:
1. Услуга Backup as a Service на базе Veeam Backup позволяет получить необходимое дисковое пространство для хранения и восстановления резервных копий из хранилища. Дополнительно к этому мы можем оказывать гарантированное восстановление по заданному времени в режимах:
1. SLA «Базовый» 10-19/5
2. SLA «Приоритетный» 9-21/7
3. SLA «Критичный» 24/7
4. SLA «VIP» 24/7
2. При использовании Veeam Endpoint Protection бэкап делается в наш Veeam, а оплата происходит согласно табличке тарифов за предоставленное дисковое пространство.
3. Используя услугу IaaS, арендуется сервер (VM) для шары (Linux или Windows – зависит от предпочтений), арендатор самостоятельно поднимает и настраивает VM и делает там шару для складирования бэкапов, затем самостоятельно соединяет сервер (VM) в облаке с сервером бэкапа. Все ресурсы можно добавлять или изменять через VMware vCloud Director в режиме реального времени.
Бэкапьтесь в облако, друзья
Сегодня мне хотелось бы еще раз пройтись по набившему оскомину резервному копированию в облако. Рассуждать на тему хорошо это или плохо, я не буду, но хочу поделиться примерами реализаций решений для этого самого облачного резервного копирования — от готового ПО до костылей на велосипедах.
Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.
3-2-1, поехали
Считается, что история правила бэкапа «3-2-1» начинается с Питера Крога (Peter Krogh), который изложил его в книге «Управление цифровыми активами для фотографов». Вкратце напомню этот принцип:
Лично я чаще всего использую чуть другие правила в формировании резервных копий.
Классическая схема «3-2-1».
Во-первых, в качестве изначальных данных я беру резервные копии, а во-вторых, не всегда удобно и бюджетно хранить их на носителях различного типа — особенно для малого и среднего бизнеса. Моя обычная стратегия хранения резервных копий такова:
С оперативными и архивными резервными копиями обычно все достаточно просто, разве что следует придерживаться определенных рекомендаций. Один из вариантов таких рекомендаций — под спойлером.
А вот с удаленными резервными копиями вопросов много. В частности, надо выбирать, где хранить эти самые копии и чем их туда забрасывать. Сначала приведу несколько примеров «где».
Выбираем уютное облако
Одним из вариантов будет простая и незамысловатая аренда выделенного сервера или установка своего сервера в ЦОД на колокейшн.
Действительно, «облако», которое построил сам, дает больше контроля над происходящим, да и выбор решения для хранения и непосредственно резервного копирования остается на усмотрение системного администратора. Можно даже сервер включить в домен «на земле», как я описывал в статье «Как я базы 1С в Германии прятал».
С другой стороны, контроль означает и ответственность — необходимо будет мониторить состояние сервера на случай аппаратных и программных проблем, при этом недостаток облаков в виде зависимости от интернета и вопроса доверия сторонним людям никто не отменял.
А не ваш ли это арендованный сервер у недорогого хостера?
Другим вариантом будет использование специализированных сервисов, которые создавались как раз для хранения резервных копий. Самым известным примером являются сервисы Amazon Glacier. Они окутаны легендами на тему используемых технологий — начиная от ленточных кассет и заканчивая blu ray-дисками и робо-руками. Но официально это недорогие HDD.
В отличие от арендованного сервера, решение уже начинает пахнуть кровавым энтерпрайзом со многими «девятками надежности» после запятой. Правда, как и многое у веб-сервисов Amazon, он обладает непростой формулой расчета стоимости. Если грубо упрощать, то загрузка данных на сервис — бесплатна, хранение — совсем недорогое ($1 за 1 Тб в месяц), а вот за получение данных придется заплатить. Как на старых ярмарках — «вход бесплатный, выход 15 копеек».
Классические сервисы хранения данных вроде Amazon S3 и Yandex Object Storage тоже, конечно, можно использовать для резервных копий, но ценник в таком случае будет менее гуманный —
Третьим вариантом будет использование облачных хранилищ, которые не очень предназначены для хранения резервных копий компании, а больше ориентированы на простых пользователей. Приведу лишь несколько из них, которые на слуху:
Я сейчас не буду сравнивать облачные платформы, отдам это на откуп многочисленным материалам в сети. Например, статье «Облачные хранилища для физических лиц: что выбрать и почему». Лично я для своих нужд остановился на Яндекс.Диске, потому что он один из немногих, кто на бесплатных планах умеет 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 до GNU\Linux, работать можно как через веб-интерфейс, так и через командную строку, также есть и шифрование бэкапов «из коробки».
Интерфейс 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.
Ну и при резервном копировании в облако я настоятельно рекомендую шифровать архивы, чтоб не оказаться в ситуации как герой стихотворения известного в определенных кругах поэта Айклауда Фон Браузера, строкой которого и названа эта статья.
В комментариях предлагаю не разводить холивар на тему рациональности облачного резервного копирования, а поделится своим любимым инструментом бэкапа.