Настройка rclone яндекс диск
В данной инструкции рассмотрим разные примеры настройки утилиты rclone для хранения архивов в облаке. По мере возможности, данные примеры будут пополняться.
Выполним синхронизацию данных с удаленным каталогом на сервере FTP.
Переходим в режим конфигурирования rclone:
Создаем новую конфигурацию:
Даем понятное название для нашего соединения:
Среди списка возможных шаблонов выбираем FTP Connection:
14 / FTP Connection
\ (ftp)
* на момент обновления инструкции данный шаблон находится под номером 14.
Указываем адрес сервера FTP:
Имя учетной записи для подключения к серверу FTP:
Порт (как правило, это 21):
На запрос использования пароля, отвечаем y (ввести свой пароль):
FTP password
y) Yes type in my own password
g) Generate random password
y/g> y
И дважды вводим пароль для подключения к FTP-серверу:
Enter the password:
password:
Confirm the password:
password:
Если удаленный сервер для подключения требует TLS, в соответствующей опции задаем значение true:
* в противном случае оставляем поле незаполненным или ставим false.
На остальные опции отвечаем по умолчанию, нажимая Enter.
Подтверждаем, что ранее введенные данные верны:
y) Yes this is OK (default)
e) Edit this remote
d) Delete this remote
y/e/d> y
Готово. Мы можем посмотреть содержимое каталога на сервере FTP:
rclone ls "BackupFTP":
* обратите внимание, что так как название в данном примере задано с пробелами, мы пишем его в кавычках.
Готово. Действия, которые можно выполнить описаны ниже.
Пример дополнительный параметров:
При конфигурировании FTP система запрашивает, хотим ли мы сконфигурировать дополнительные параметры. Если нажать да:
Edit advanced config? (y/n)
y) Yes
n) No (default)
y/n> y
. та нам будут заданы дополнительные вопросы. Среди который, наиболее интересен про проверку валидации сертификата:
Очень часто, при настройке TLS на FTP-сервере используют самоподписанный сертификат. Данная опция позволит rclone не завершать работу с ошибкой при проверке валидности сертификата.
Что делать?
Пока использовать свой client_id и жить дальше. Но, судя по ответу техподдержки, можно ждать продолжения охоты на ведьм и блокировки также других client_id, user-agent rclone или, даже, какие-то эвристические способы заблокировать утилиту.
P.S. Я искренне надеюсь, что имела место простая ошибка или недопонимание. В Яндексе работают отличные специалисты (много с кем я знаком лично) и среди них, уверен, есть пользователи rclone.
Обновление 24.02.2020:
В выпуске 690 подкаста Радио-Т, соведущим которого также является уважаемый Бобук, обсуждалась блокировка rclone. Начало на 1:51:40.
Обновление 27.02.2020:
Авторизация по стандартному client_id снова работает.
В предыдущих публикациях мы уже не раз рассказывали о полезных утилитах для работы с нашим облачным хранилищем. Сегодня мы поговорим ещё об одном интересном, простом в обращении и — не побоимся этого слова — уникальном инструменте. Знакомьтесь: rclone. Разработчики описывают его краткой и ёмкой фразой «rsync для облачных хранилищ».
Основная функция rclone — это синхронизация данных в хранилище и на локальной машине. Утилита несомненна окажется полезной для широкого круга пользователей облачного хранилища. Её можно использовать и для резервного копирования, и в работе со статическими сайтами…
Есть у rclone и опции, которых нет ни у одного другого инструмента аналогичного плана. Подробнее обо всём этом мы расскажем ниже.
Полезные команды для работы с Rclone
Просмотр списка контейнеров в хранилище:
rclone lsd [remote]:
Создание нового контейнера:
rclone mkdir [remote]:[имя контейнера]
* где [имя контейнера] — путь до конечной папки.
Просмотр списка файлов в контейнере:
rclone ls [remote]:[имя контейнера]
Копирование файлов с локальной машины в хранилище:
rclone copy /home/local/directory [remote]:[имя контейнера]
Синхронизация файлов на локальной машине и в хранилище:
rclone sync /home/local/directory [remote]:[имя контейнера]
Синхронизация файлов в хранилище с файлами на локальной машине:
rclone sync [remote]:[имя контейнера] /home/local/directory
При выполнении операций копирования и синхронизации rclone проверяет все файлы по дате и времени изменения или md5-сумме. Из директории-источника в директорию назначения передаются те файлы, которые были изменены.
О rclone
Немного справки:
rclone — достаточно известная открытая утилита для работы с облачными хранилищами (неоднократно раз, два, три упоминалась на Хабре). Автор называет её "rsync for cloud storage", что довольно ёмко. Но этим функциональность не ограничивается: помимо функций rsync она ещё может монтировать диски, выполнять функцию ncdu (что, кстати, мне позволило однажды обнаружить неправильный подсчёт свободного места на Яндекс.Диске и успешно решить эту проблему через техподдержку), а также кучу всего ещё. Утилита поддерживает как десятки облачных хранилищ, так и более традиционные протоколы — WebDAV, FTP, rsync и другие. Для доступа к Яндекс.Диску утилита использует официальный публичный API Диска.
Утилита поистине уникальна и (по моему мнению) представляет из себя тот класс программ, которые ставишь один раз, а пользу они приносят постоянно.
Загрузка объектов большого размера
Проверим скорость работы rclone ещё на одном тесте: попытаемся загрузить в хранилище объект большого размера — более 20 ГБ. Файлы до 20 ГБ загружаются в хранилище при помощи стандартных команд. Процедура загрузки файлов большего размера проходит по-другому: файл делится на сегменты, которые загружаются в отдельный контейнер.
Rclone по умолчанию делит такие файлы на сегменты размером по 5ГБ каждый. В случае необходимости размер сегмента можно изменить с помощью опции -swift-chunk-size. Мы попробовали загрузить в хранилище файл размером 25 ГБ. Rclone справился с этой задачей за 11 минут 14 секунд. Результат, как видим, вполне неплохой.
Configuration
Here is an example of making a yandex configuration. First run
This will guide you through an interactive setup process:
See the remote setup docs for how to set it up on a machine with no Internet browser available.
Once configured you can then use rclone like this,
See top level directories
Make a new directory
List the contents of a directory
Sync /home/local/directory to the remote path, deleting any excess files in the path.
Yandex paths may be as deep as required, e.g. remote:directory/subdirectory .
Emptying Trash
If you wish to empty your trash you can use the rclone cleanup remote: command which will permanently delete all your trashed files. This command does not take any path arguments.
Modified time
Modified times are supported and are stored accurate to 1 ns in custom metadata called rclone_modified in RFC3339 with nanoseconds format.
Выводы?
Совсем недавно, уважаемый bobuk в своём посте здесь на Хабре писал, что Яндекс считает, что:
Мы в Яндексе считаем, что современный интернет невозможен без культуры open source и людей, которые инвестируют свое время в разработку программ с открытым кодом.
А на практике получается совсем иначе. Отличную утилиту блокируют за что-то, что не запрещено правилами сервиса. За то, что утилита позволяет использовать открытый публичный API Диска по прямому назначению — загружать файлы. Блокируют не за нарушение правил сервиса, а потому что могут.
Вдвойне странно то, что заблокированы не конкретные нарушители правил (тоже непонятно каких, в правилах использование диска для резервных копий нигде не запрещено). Заблокирован инструмент, функция осуществления резервного копирования в котором лишь одна из многих.
Что такое инфраструктурный компонент и почему их нельзя использовать с диском тоже не понятно. Даже браузер может быть использован как "инфраструктурный компонент", не стоит ли запретить пользоваться диском в браузере?
Advanced options
Here are the advanced options specific to yandex (Yandex Disk).
--yandex-token
OAuth Access Token as a JSON blob.
- Config: token
- Env Var: RCLONE_YANDEX_TOKEN
- Type: string
- Required: false
--yandex-auth-url
Auth server URL.
Leave blank to use the provider defaults.
- Config: auth_url
- Env Var: RCLONE_YANDEX_AUTH_URL
- Type: string
- Required: false
--yandex-token-url
Token server url.
Leave blank to use the provider defaults.
- Config: token_url
- Env Var: RCLONE_YANDEX_TOKEN_URL
- Type: string
- Required: false
--yandex-hard-delete
Delete files permanently rather than putting them into the trash.
- Config: hard_delete
- Env Var: RCLONE_YANDEX_HARD_DELETE
- Type: bool
- Default: false
--yandex-encoding
The encoding for the backend.
- Config: encoding
- Env Var: RCLONE_YANDEX_ENCODING
- Type: MultiEncoder
- Default: Slash,Del,Ctl,InvalidUtf8,Dot
Rclone копирует по-кругу один файл
В моем случае, программа копировала все данные на удаленное хранилище и после этого, вместо того, чтобы завершить работу, начинала копировать файл(ы) по новой.
Причина: как выяснилось, проблема в версии приложения.
Решение: в моем случае, помогла установка более ранней версии приложения. Список можно увидеть на официальном сайте.
Yandex Disk is a cloud storage solution created by Yandex.
Limitations
Having a Yandex Mail account is mandatory to use the Yandex.Disk subscription. Token generation will work without a mail account, but Rclone won't be able to complete any actions.
К написанию этого поста привела довольно странная ошибка, которую вчера вечером на ноутбуке с Linux (да, я из тех странных людей, кто использует GNU/Linux на ноутбуке) я получил вместо содержимого своего Яндекс.Диска:
Первая мысль: сеть отвалилась, ничего страшного. Но при попытке перемонтировать директорию появилась новая ошибка:
Это было уже странно. Токен протух? Не беда, авторизую заново!
Это приложение заблокировано за вредоносные действия, поэтому доступ не разрешён (unauthorized_client).
Первая мысль: чтоооо?
Возможные проблемы
Пока, я столкнулся с единственной проблемой.
Quota information
To view your current quota you can use the rclone about remote: command which will display your usage limit (quota) and the current usage.
Что произошло?
Обратившись к Google я сразу понял, что не одинок. Есть баг в официальном гитхабе, а также обсуждение на официальном форуме.
Краткое содержание: client_id утилиты заблокирован Яндекс.Диском, из-за чего авторизоваться больше нельзя. Можно попробовать поменять client_id, но не факт, что та же участь не постигнет и новый id.
Ответ поддержки опубликован на том же форуме:
Дело в том, что программа Rclone позволяет использовать Яндекс.Диск в качестве инфраструктурного компонента, а Яндекс.Диск — это персональный сервис, который не рассчитан на решение таких задач. Поэтому мы не поддерживаем работу связки Rclone — Яндекс.Диск.
"Инфраструктурный компонент"? Ну раз нельзя, то наверное это описано в правилах подумал я и ничего такого в правилах самого диска или его публичного API я не нашёл.
Ладно, напишем в поддержку.
Первый ответ прилетает 1 в 1 тот, что опубликован выше (про "инфраструктурный компонент"). Окей, мы не гордые.
А подскажите пожалуйста, какое правило сервиса это нарушает?
Я изучил условия использования Яндекс диска и никаких запретов на использование "в качестве инфраструктурного компонента" там нет.
Более того, я не могу использовать утилиту с личного ноутбука для работы с диском. Это уже совсем никак под " инфраструктурный компонент" не подпадает. Штатный клиент диска ужасен, уж простите.
Сергей, дело в том, что Яндекс.Диск — это в первую очередь персональный сервис, который не рассчитан на загрузку резервных копий в автоматическом режиме.
Вы можете синхронизировать данные между вашим компьютером и Яндекс.Диском, а также пользоваться веб-интерфейсом Диска для загрузки файлов и работы с ними.
Если вас по каким-то причинам не устраивает наша программа, пожалуйста, озвучьте их. Традиционно мы прислушиваемся к мнению пользователей при выпуске обновлений продукта.
Вы не ответили на мой вопрос. Подскажите пожалуйста, какой пункт правил сервиса нарушает использование rclone? Я внимательно изучил правила по вашей ссылке (ещё до того, как вы из прислали).
А теперь вы блокируете OpenSource утилиту по надуманной причине.
Кстати, программа не осуществляет "загрузку резервных копий в автоматическом режиме", программа предназначена для работы с облачными хранилищами, в том числе для синхронизации данных между компьютером и Яндекс.Диском. И этой мой основной use-case утилиты, который теперь недоступен.
Пользователь также предупреждается об этом в п. 4.6. «Условий использования Яндекс.Диска».
Обратите внимание, что «Условия использования Яндекс.Диска» также устанавливают для Пользователя обязанность действовать добросовестно и воздержаться от злоупотребления функциями Сервиса. Пользователь в том числе обязуется воздержаться от организации массового файлообмена с использованием функций Сервиса.
Яндекс имеет право применять правила, лимиты и ограничения, направленные на предотвращение, ограничение и пресечение массового файлообмена по правилам п. 4.5. настоящих «Условий».
Последний ответ привнёс ясности. Особенно, первые два абзаца со ссылкой на п. 3.1. «Пользовательского соглашения» Яндекс и п. 4.6. «Условий использования Яндекс.Диска». Текст 4.6 тут не приведён, приведу:
4.6. Яндекс оставляет за собой право устанавливать любые правила, лимиты и ограничения (технические, юридические, организационные или иные) на использование Сервиса, и может менять их по собственному усмотрению, без предварительного уведомления Пользователя. В случаях, когда это не запрещено законодательством, указанные правила, лимиты и ограничения могут быть различными для различных категорий Пользователей.
MD5 checksums
MD5 checksums are natively supported by Yandex Disk.
Установка и первичная настройка
Несомненным плюсом и несомненным преимуществом rclone перед другими продуктами аналогичного плана является поддержка множества операционных систем: Linux, Windows, MacOS, Solaris, FreeBSD, OpenBSD, NetBSD и Plan 9.
Ссылки для скачивания пакетов для всех названных ОС можно найти на странице загрузки.
Мы будем описывать особенности работы c rclone на материале ОС Linux. Для установки нам потребуется скачать необходимый пакет, а далее выполнить:
На консоли появится такой диалог:
Выбираем n и нажимаем Enter. Далее нам нужно будет указать имя подключения к удалённому хранилищу:
Указываем любое имя (например, Selectel) и переходим к следующему пункту:
Выбираем цифру 10 (swift) и нажимаем Enter. После этого программа запросит имя пользователя и пароль:
Нашего хранилища в списке нет, поэтому укажем адрес вручную:
Два следующих пункта (tenant и region) являются факультативными, и их можно пропустить. В последнем вопросе диалога нам будет предложено ещё раз проверить все настройки:
Если всё правильно, выбираем вариант y и нажимаем Enter.
Заключение
Rclone — вполне интересный и перспективный инструмент, который вполне можно рекомендовать к использованию. Если вам кажется, что мы о чём-то забыли рассказать, сообщите нам об этом, и мы обязательно расширим наш обзор.
А если вы уже знакомы с rclone — делитесь опытом в комментариях.
Если вы по тем или иным причинам не можете оставлять комментарии здесь — добро пожаловать в наш блог .
Сегодня мне хотелось бы еще раз пройтись по набившему оскомину резервному копированию в облако. Рассуждать на тему хорошо это или плохо, я не буду, но хочу поделиться примерами реализаций решений для этого самого облачного резервного копирования — от готового ПО до костылей на велосипедах.
Еще не бэкапитесь в облако или хотите почитать про варианты решений? Прошу под кат.
Считается, что история правила бэкапа «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 до 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.
Ну и при резервном копировании в облако я настоятельно рекомендую шифровать архивы, чтоб не оказаться в ситуации как герой стихотворения известного в определенных кругах поэта Айклауда Фон Браузера, строкой которого и названа эта статья.
В комментариях предлагаю не разводить холивар на тему рациональности облачного резервного копирования, а поделится своим любимым инструментом бэкапа.
Standard options
Here are the standard options specific to yandex (Yandex Disk).
--yandex-client-id
OAuth Client Id.
Leave blank normally.
- Config: client_id
- Env Var: RCLONE_YANDEX_CLIENT_ID
- Type: string
- Required: false
--yandex-client-secret
OAuth Client Secret.
Leave blank normally.
- Config: client_secret
- Env Var: RCLONE_YANDEX_CLIENT_SECRET
- Type: string
- Required: false
Restricted filename characters
Invalid UTF-8 bytes will also be replaced, as they can't be used in JSON strings.
Примеры команд
Синтаксис команд для работы с хранилищем прост:
При выполнении операций копирования и синхронизации rclone проверяет все файлы по дате и времени изменения или md5-сумме. Из директории-источника в директорию назначения передаются те файлы, которые были изменены.
Подробное описывать все команды мы в этой статье не будем: обо всё можно прочитать в официальной документации. Также краткую справку можно получить с помощью команды:
Большинство функций rclone — такие же, как у других инструментов для работы с облачными хранилищами. Но есть у него одна уникальная функция, которой нет ни у одного из известных нам инструментов: перенос данных из одного облачного хранилища в другое.
Рассмотрим следующий практический пример: у нас есть папка с фотографиями на Google Docs, и её содержимое нужно перенести в наше облачное хранилище. С помощью rclone это делается очень просто. Создаём новое подключение; в списке доступных облачных хранилище выбираем Google Drive. После этого нам будет предложено указать два параметра: client_id и client_secret. В ответ на соответствующие вопросы не ничего не вводим и просто нажимаем Enter.
Далее нам будет задан следующий вопрос:
Выбираем ответ «нет» (n). Rclone сгенерирует ссылку для получения кода:
Откроем эту ссылку в браузере и дадим rclone разрешение на доступ к файлам.
После этого API Google Drive вернёт код, который нужно будет вставить в ответ на вопрос:
Вот и всё. Подключение к Google Drive настроено, и можно приступать к копированию:
С задачей копирования файлов rclone справляется достаточно быстро: мы скопировали папку с фотографиями объёмом 1,8 ГБ за 1 минуту 55 секунд.
В ходе экспериментов мы также выяснили, что rclone без проблем копирует и текстовые документы GoogleDocs, преобразуя их в формат docx.
Яндекс диск
Для работы с яндекс диском необходима авторизация через браузер (OAuth). Для того, чтобы запустить утилиту на сервере без графики, мы должны сначала установить rclone на компьютер с GUI (это может быть Windows или Linux Desktop).
И так, на компьютере с браузером запускаем конфигурацию утилиты:
* если запускаем в Windows, то сначала переходим в каталог, куда скопировали утилиту.
Создаем новую конфигурацию:
Даем понятное название для нашего соединения:
Среди списка возможных шаблонов выбираем Yandex Disk:
39 / Yandex Disk
\ "yandex"
* на момент обновления инструкции данный шаблон находится под номером 39.
Идентификатор клиента и пароль оставляем пустыми:
На запрос внесениея расширенных настроек отвечаем отрицательно:
Edit advanced config?
y) Yes
n) No (default)
y/n> n
На вопрос использования автоконфигурации отвечаем y>:
Use auto config?
* Say Y if not sure
* Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> y
Откроется окно браузера — вводим наши логин и пароль для доступа к Яндекс диску. В следующем окне кликаем по Log in as . :
Success!
Закрываем браузер. Выходим из конфигурирования rclone:
Смотрим содержимое конфигурационного файла. Наши действия немного будут различаться в зависимости от системы, в которой мы работаем.
а) в системах на базе Linux:
б) для систем Windows:
Мы увидим что-то на подобие:
[YandexDisk]
type = yandex
token =
* конфигураций может быть несколько — нас интересует yandex с тем именем, которое мы задавали в настройке.
Копируем содержимое и переходим на целевой сервер.
Открываем конфигурационный файл для rclone:
* если в нашей системе уже есть конфигурационный файл и его путь отличается от нашего, то можено ввести команду:
rclone --help | grep -e '--config'
. которая покажет путь до него.
Ввносим содержимое, которое скопировали, например:
[YandexDisk]
type = yandex
token =
Готово, можно проверить командой:
rclone lsd YandexDisk:
Читайте также: