Общее описание

Наконец, обновлятор позволяет не только создавать и хранить архивы локально, но ещё и передаёт эти архивы на удалённые сервера (в так называемые облачные сервисы).

Список удалённых серверов настраивается на закладке "Настройки программы", кнопка "Облака":

В данный момент поддерживаются следующие типы облачных хранилищ:

• Ftp
• Ssh
• Webdav
• Яндекс.Диск (на бесплатном тарифе дают 10 гигабайт, но обратите внимание, что с недавних пор Яндекс снизил цены и, например, 1 терабайт стоит всего 200 рублей в месяц)
• Гугл.Диск (на бесплатном тарифе дают 15 гигабайт)
• Mega.nz (на бесплатном тарифе дают 15 гигабайт)

Добавленные в обновлятор облака можно выбирать в качестве дополнительных хранилищ в двух местах.

Прежде всего это общие настройки архивации баз (кнопка "Дополнительные настройки", закладка "Архивация баз"):

Либо же можно переопределить эти настройки уже в свойствах конкретных баз:

Форма выбора дополнительных хранилищ выглядит вот так:

Здесь мы можем выбрать конкретные облака и настроить гибкое хранение количества копий (в том числе периодических).

Нюансы

Нужна ли дополнительная проверка закачанных в облако файлов

Обратите внимание на то, что когда вы добавляете новое облако там есть опция (которая выключена по умолчанию):

Если поставить эту галку, то обновлятор после закачки файла в облако будет скачивать его назад и сверять с оригинальным. Это гарантирует нам 100% целостность архивов в облаке, но примерно в 2 раза снижает скорость закачки.

Нужна ли эта галка и что вообще можно сказать о проверке целостности закачиваемых в облака архивов? Рассмотрим этот вопрос отдельно по облакам.

Ftp

Обновлятор поддерживает и применяет по умолчанию проверку целостности закачанного по Ftp файла, запрашивая у сервера Ftp его (файла) контрольную сумму (checksum).

Но, к сожалению, не многие сервера Ftp поддерживают такую возможность.

Как узнать поддерживает ли ваш сервер Ftp вычисление контрольных сумм файлов? Для этого выполните тестирование облака из обновлятора:

И обратите внимание на строку checksum:

Если там стоит yes - можете быть уверены в целостности закачиваемых архивов. Галка "После передачи файла в облако скачивать его обратно..." вам точно не требуется.

Если же там стоит no, то имеет смысл поставить галку "После передачи файла в облако скачивать его обратно...", если вам позволяет скорость закачки. Но обычно по Ftp скорость закачки хорошая и превышает в 2 и более раза закачку архивов по http.

Ssh

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

Гугл.Диск

Гугл.Диск поддерживает вычисление контрольных сумм закачанных файлов. И обновлятор использует эту возможность, для проверки целостности архивов в облаке.

Поэтому в случае с Гугл.Диск галка "После передачи файла в облако скачивать его обратно..." совершенно точно не нужна.

Яндекс.Диск, Mega.nz

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

WebDav

Этот протокол сам по себе не поддерживает вычисление контрольных сумм для закачанных файлов, но если он работает поверх https (как например в случае с яндекс-диском), то можно не волноваться.

Почему для работы с облаками из обновлятора требуется .Net Framework 4.5

Как известно, для работы обновлятора достаточно установленного .Net Framework 2.0.

Но для того, чтобы работать с облаками нужно дополнительно установить .Net Framework 4.5.

Эта необходимость вызвана требованиями различных библиотек (автором которых я не являюсь) от поставщиков облачных сервисов, которые использует обновлятор для доступа к облакам. К тому же в будущем я планирую расширять количество доступных облачных сервисов, и потому я вынужден был для реализации облаков использовать столь высокий framework.

Я заранее приношу извинения обладателям Windows XP и Windows Server 2003, потому что .Net Framework 4.5 установить на эти устаревшие ОС не получится. Во всём остальном (кроме облаков) обновлятор будет работать на этих ОС прекрасно.

Почему это 100% защита от шифровальщиков

1. Потому что в облако заливаются только те архивы, что были созданы обновлятором.
2. После того как эти архивы залились в облако - повторно они туда не заливаются ни при каких условиях (это исключает заливку в облака зашифрованных вирусом архивов).
3. У шифровальщика нет прямого доступа к облаку, так как обновлятор заливает архивы через api облака, не подключая это облако, например, в качестве диска.

Как настроить ограничения (расписание) для загрузки в облака

Буду рассказывать по порядку.

Замечание №1

Прежде всего обратите внимание на вот эту настройку:

Это число (по умолчанию 9) означает максимально возможное число одновременных (параллельных) загрузок во все облака вместе взятые.

При такой настройке получается, что даже если у нас 100 облаков, в которые нужно залить 1000 файлов - в один момент будет заливаться не более 9 файлов.

Замечание №2

Что касается максимально возможного числа одновременных загрузок в конкретное облако, то оно настраивается в свойствах самого облака:

Это число (по умолчанию 3) означает максимально возможное число одновременных (параллельных) загрузок в конкретное облако.

Замечание №3

Для более гибкого управления трафиком существует возможность настраивать расписание ограничений загрузок:

По умолчанию это расписание пусто, что означает заливку в максимально указанное количество одновременных загрузок (с учётом ограничений конкретных облаков) на максимальной скорости:

Сейчас я покажу простейшие примеры настройки этого расписания.

Пример №1

Требуется, чтобы по рабочим дням с 9 до 18 общая загрузка в облака потребляла не более 300 килобайт в секунду.

Мы принимаем решение на это время оставить всего три одновременные загрузки по 100 килобайт каждая.

Вот это расписание:

Пример №2

Требуется, чтобы в дополнение к предыдущему условию с 12-30 до 15-30 по средам загрузка вообще прекращала свою работу.

Добавим к расписанию такую строчку:

Главное тут - то, что мы установили максимальное количество одновременных загрузок в ноль.

Пример №3

Требуется, чтобы в дополнение к предыдущим условиям по субботам загрузка работала в 6 одновременных потоков, по 300 килобайт каждый:

Обратите внимание, что в дни и время, которое не указано в расписании загрузка будет по прежнему работать в максимальное количество потоков (9 штук) на максимальной скорости.

Пример №4

Наконец, в дополнение ко всем предыдущим условиям сделаем так, что в воскресенье до обеда загрузка не работала (в это время приходит админ и ему нужен трафик):

Технические подробности загрузки в облака для администраторов

Пользователи меня всё равно расспрашивают - как устроена загрузка в облака изнутри; зачем для входа в диалог настройки облаков нужны права администратора... и другие вопросы.

Итак, поехали... Сразу прошу прощение за сумбурность изложения.

Как устроена загрузка в облака изнутри?

После того как мы настроили облака и нажали волшебную кнопку "ОК"...

... обновлятор создаёт в планировщике заданий Windows следующую задачу:

Создав эту задачу, обновлятор сразу запускает её на выполнение.

Что выполняет эта задача? Она запускает процесс Updater1C.CloudManager.exe (менеджер загрузки), который постоянно висит в фоне и ожидает поступления новых архивов, сделанных обновлятором.

Созданная задача выполняет запуск этого процесса при загрузке компьютера и каждый час. Зачем это делается так часто? Для того, чтобы исключить зависания менеджера загрузки. В этом случае новый экземпляр определит, что уже работающий менеджер загрузки завис и его нужно перезапустить.

Почему вообще может произойти зависание менеджера загрузки? Работа с внешними ресурсами (а обновлятор поддерживает сразу несколько типов облаков) довольно непредсказуемая вещь - всякое бывает.

Что же делает наш менеджер загрузки, когда видит, что поступили архивы для заливки в облака?

Он начинает загружать эти архивы (в соответствии с расписанием заливки и ограничениями облаков), но не сам.

На каждую закачку архива он создаёт отдельный процесс, который называется Updater1C.CloudSender.exe (загрузчик в облака).

И получается, что если мы видим, что в менеджере задач висит 3 процесса Updater1C.CloudSender.exe, то это означает, что сейчас в облака заливаются 3 файла.

Нужно понимать, что загрузка одного файла никогда не распараллеливается. Один файл всегда целиком и полностью загружается одним загрузчиком (процесс Updater1C.CloudSender.exe).

Зачем для настройки облаков требуются права администратора?

Права администратора требуются для того, чтобы обновлятор, а также менеджер загрузки могли управлять своими же собственными процессами (Updater1C.CloudManager.exe  и Updater1C.CloudSender.exe), которые работают в фоне и отвечают за загрузку в облака.

Без прав администратора обновлятор не сможет "убить" зависший менеджер загрузки (Updater1C.CloudManager.exe) или просто сделать его перезапуск после изменившихся настроек облаков.

Без прав администратора менеджер загрузки не сможет "убить" зависшие загрузчики (Updater1C.CloudSender.exe) или сделать их перезапуск.

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

И именно поэтому задание в планировщике для запуска менеджера загрузки в облака настраивается с наивысшими привилегиями.

Зачем задание планировщика "передача архивов в облака" настраивается на запуск вне зависимости от регистрации пользователя?

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

А делается это только для одной вещи. Чтобы менеджер загрузки в облака мог работать даже, если за компьютером никто не "залогинен". Для серверов это обычное дело.

Зачем архивы при загрузки разбиваются на части?

По умолчанию перед загрузкой в облако обновлятор разбивает архив на части по 50 мегабайт. Причём делает он это стандартным разбиванием архива на тома используя возможности архиватора 7-zip.

Это значит, что эти части могут быть легко открыты любым архиватором (хоть 7-zip, хоть winrar).

Для этого достаточно скачать их все на компьютер, а затем открыть в архиваторе первую часть (имя которой оканчивается на .001).

Сами эти части никак не сжимаются - это простое разрезание файла на куски.

А теперь - зачем это делается. Это потому, что большинство облаков не поддерживают "докачку". А разрывы при закачки данных в облака - не такое уж редкое явление.

И если мы откажемся от разрезания файлов на куски приемлемого размера - то при стечении некоторых обстоятельств мы вообще никогда не зальём файл.

Предположим, что нам надо залить 2 гигабайта.

Если мы заливаем этот файл целиком и произошёл временный обрыв связи (или мы просто изменили настройки менеджера облаков и произошёл его перезапуск) - мы начнём его заливку с самого начала.

А если мы заливаем по кусочкам 50 мегабайт, то при разрыве мы будем повторно закачивать лишь этот маленький кусочек.

 Также следует учитывать , что если вы передаёте архивы через webdav или на яндекс-диск, то чем больший размер части вы установите, тем больше будет загрузка процессора в начальный момент передачи. Это связано с техническими особенностями работы библиотеки, которая используется обновлятором для передачи по протоколу webdav.

Так можно или нет увеличивать размер загружаемых частей архивов?

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

Конечно, "расшарить" один файл удобнее, чем делать то же самое для группы файлов или для папки.

Поэтому, конечно, вы можете установить размер части для конкретного облака, скажем, 3000 мегабайт:

Но вы должны понимать к чему это может приводить при нестабильном интернет-соединении (см. ответ на вопрос пунктом выше).

Тут или удобство (и загрузка без разбивки на части) или надёжность (и загрузка с разбиением на небольшие части). Что выбирать в том или ином случае - решать только вам.

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

И ещё один  важный момент . Если вы передаёте архивы через webdav или на яндекс-диск, то нужно учитывать - чем больший размер части вы установите, тем больше будет загрузка процессора в начальный момент передачи. Это связано с техническими особенностями работы библиотеки, которая используется обновлятором для передачи по протоколу webdav.

Откуда грузится файл в облако; в какой момент происходит нарезка файла на куски; после загрузки "куски" очищаются?

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

Проблемы с загрузкой в облака?

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

Внимание. Обязательно просмотрите все моменты до конца (особенно обратите внимание на момент #9).

Момент #1

Скорее всего дело в том, что облако-то вы создали...

... но при этом не выбрали его в настройках архивации.

Для всех баз в целом это делается в дополнительных настройках обновлятора, на закладке "Архивация баз":

Вы также можете переопределить эту настройку уже на уровне свойств конкретных баз:

Чтобы проверить себя - сделайте архивацию базы и тут же зайдите в менеджер облаков:

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

Момент #2

Предположим, что очередь загрузки у вас не пустая, но файлы в облака так и не загружаются.

Тогда поступите так:

1. Ещё раз перепроверьте логин и пароль учётной записи, указанные в обновляторе. Это нужно сделать обязательно.
2. В вашем сервисе могут быть включены пароли приложений. Тогда для обновлятора придётся создать отдельный пароль (Яндекс-Диск об этом рассказывает здесь). Пароли приложений могут устаревать при смене основного пароля сервиса.
3. Протестируйте облако на ошибки (кнопка "Протестировать облако" в менеджере облаков).
4. Если есть ошибки и они вам не понятны - напишите мне на почту helpme1c.box@gmail.com приложив снимок окна с результатами тестирования.
5. Если ошибок при тестировании нет, то обратите внимание на колонку "Ошибки" в менеджере облаков. Если там есть ошибки - откройте их по ссылке и также пришлите мне на helpme1c.box@gmail.com

Момент #3

После настройки облаков через диспетчер задач убедитесь, что у вас в фоне работает процесс Updater1C.CloudManager.exe (при его поиске в диспетчере задач нажимайте кнопку "Отображать процессы всех пользователей").

Именно этот процесс отвечает за управление загрузкой в облака. Если он не работает выполните его повторную настройку нажав кнопку "Сохранить и закрыть" в окне менеджера облаков.

Момент #4

Если при нажатии кнопки "Облака" обновлятор перезапускается, но окно настройки так и не появляется:

• остановите в диспетчере задач процесс Updater1C.CloudManager.exe
• зайдите в папку обновлятора и найдите там подпапку "Logs [cloud]" (если такой папки нет, ищите "Data\Logs\cloud"), удалите её целиком

Эта проблема была решена в следующих версиях обновлятора от 2018 года. Если у вас более старая версия, обновите её нажав кнопку "Скачать новый обновлятор" внизу главного окна программы.

Момент #5

Проверьте, не закончилось ли место в облаке.

Момент #6

Бывает так, что процесс Updater1C.CloudSender.exe периодически потребляет слишком много процессорного времени. Это характерно для соединения webdav и яндекс-диска (с которым мы тоже работаем через webdav).

В этом случае я рекомендую уменьшить размер заливаемой части до стандартных 50 мегабайт (такое значение выставлено в настройках облаков по умолчанию). Именно от размера заливаемой части напрямую зависит загрузка процессора на начальном этапе закачки при соединении через webdav.

Момент #7

Ещё я хочу вас сразу предостеречь от попыток регистрации пачки бесплатных яндекс-дисков для хранения своих бэкапов.

Яндекс сейчас для регистрации использует обязательное подтверждение по телефону и если вы будете регистрировать все ящики на один и тот же телефон - яндексу это не понравится, проверено

При такой тактике яндекс начинает требовать смену пароля у всех ящиков и даже может заблокировать такие ящики (доступ вернут при обращении в службу поддержки).

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

Либо рассмотреть возможность платного тарифа яндекс-диска - цены там сейчас ну просто смешные. Например, вместо того чтобы заводить 100 бесплатных яндекс-дисков и мучиться с их регистрацией, хранением паролей и прочего... почему-бы не платить 200 рублей в месяц за один яндекс-диск объёмом 1 террабайт?

Если используете яндекс-диск для работы - 200 рублей в месяц ИМХО не те деньги, чтобы изворачиваться с бесплатными дисками.

Момент #8

Яндекс-диск с недавних пор ввёл ограничения на возможности параллельной загрузки файлов.

Если у вас всё работало, а затем вдруг в отчётах загрузки в облако посыпались ошибки с кодом 429 (слишком много запросов), то причина именно в этих ограничениях.

В этом случае нужно зайти в свойства облака в обновляторе и установить значение 1 в поле "Макс. одновременных загрузок".

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

Момент #9

Зайдите в дополнительные настройки программы и нажмите кнопку "Облака":

В списке облаков обратите внимание на колонку "Очередь загрузки":

Если там есть ссылка на незагруженные файлы, откройте её:

Если здесь есть хотя бы один файл, который не успел загрузиться в облако и уже был удалён обновлятором при чистке старых архивов, то необходимо нажать кнопку "Отменить эти загрузки". Иначе обновлятор так и будет выдавать вам предупреждение о том, что есть незагруженные файлы.

Момент #10

Зайдите в свойства облака и убедитесь, что оно не выключено случайно вами:

На этом всё Если у вас остались вопросы по настройке облаков в обновляторе или есть замечания по их работе - пожалуйста, напишите мне на helpme1c.box@gmail.com