Быстрое и надежное резервное копирование данных в облако

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

Написано, что duplicati — это практически 1-в-1 порт duplicity. Значит, во-первых, можно напрямую работать с файлами — у duplicity структура довольно самоочевидная, можно разобраться и вручную, в каком архиве что лежит. Во-вторых, раз есть portable версия, можно с ее помощью вытащить файл из резервной копии.

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

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

Если архив диска делается не пофайлово, а целиком диск, поблочно, то это делается всегда быстро — ограничение лишь в скорости работы самого диска и интернет-соединения. Естественно, сжатие отсутствует как факт, шифрование тоже под вопросом. Касательно работы архиваторов — 27 тысяч файлов 7z в быстром режиме зажимает в течении 40 секунд, интрементный архив при изменении тысячи файлов создается и заливается за 5 секунд. Если экстраполировать эти данные на Ваш архив, получается что Ваш рабочий каталог содержит минимум сотню-другую миллионов файлов, с которыми Вы постоянно работаете, и тогда да, это проблема, или же это просто огромные файлы баз данных, которые невозможно архивировать инкрементно, и тогда да, создать образ диска — лучший выбор.

Все все, уели )) не буду продавать это по 3700 за лицензию на год или 5300 за бессрочную лицензию ))) сдаюсь )). Особенно понравилось то, что bat файл требует «поддержки и внимания», добавили бы еще «технического обслуживания по регламенту и привлечения специалистов минимум уровня архитектора приложений» и я был бы раздавлен раз и навсегда ))) остальные пункты из той же серии ))) в самом деле, скриптовый файл жестко привязан к платформе из-за огромного количества зависимостей, и не может быть перенесен в другую систему, кроме как полностью переписан с привлечением независимой команды разработчиков. Позор мне )))

Прекрасно ) посмотрим что можно сделать по Вашему списку.
— Использование CMD — легко можно переписать примерно на 100 других вариантов командных оболочек;
— Используя скриптинг, Вы не используете ключи — вынести пути и так далее в ключи легко;
— Не бэкапятся открытые файлы — бекапятся. Не бекапятся только файлы, заблокированные на чтение. Через теневые копии (есть описание выше) можно и открытые и заблокированные файлы считать.
— Все сделанные бэкапы находятся в состоянии суперпозиции, они вроде и есть, но если не произведено тестовое восстановление, их как бы может и не быть — добавить в скрипт еще пару строчек на обратное скачивание и тестирование архива;
— Отсутствует уведомление в почту/мессенджер о удачном/неудачном действе, ошибках в процессе — добавить еще строчку с консольным mail — клиентом, реализующим данный функционал.
— Отсутствие проверки доступности источника, временной папки и хранилища — еще пару строк и еще немного данных для консольного mail клиента
— «безопасность» через «упрятать»,«посолить», «вероятность» — без комментариев, это вечное и реально проблемное место почти всех систем. unixforum.org/viewtopic.php?t=135935 для просто ознакомления, ну и решение — храните пароль в голове, вводите его в окошке.
— Отсутствие прогнозирования и проверки достаточности места на диске с временной папкой и в хранилище — увы, тут согласен
— Бесконечные инкременты, пока руками на полный бэкап не тыкнешь — отмечу, рабочие инкременты, которые мне и нужны. Я всегда знаю что в последнем инкременте лежит рабочий файл, если я с ним работал после создания полной версии бэкапа. В данном случае к примеру Duplicati ведет себя не лучше — бесполезно пытаться получить просто свежий файл, он всегда с сервера тянет полный бэкап;
— При создании нового полного бэкапа, Ваш скрипт сначала сносит все старые бэкапы, а только потом делает полный новый! — поменять строки местами, и сначала заказчивать тестировать, а потом сносить старый бэкап.
Таким образом, чтобы удовлетворить доброй половине Ваших желаний, всего лишь надо переписать скрипт с добавлением пары программ (использование теневых копий и консольного е-майл клиента), изменить порядок действий по проверке/удалению, и… бросить попытки курить трудозатраты на сложные системы, ибо овчинка выделки не стоит, ежедневную копию я уже имею, а отдельную копию на независимом носителе я и так делаю раз в две недели, что достаточно для домашнего использования.
И отмечу — скрипт можно использовать как пример логики, реализованной всего 2 программами. Расширить его можно всегда и любым способом. А курить родные клиенты облачного хранилища, или Duplicati с аналогами — поверьте, что курилось то курилось, список недостатков родных клиентов и программ «мы-вам-все-забекапим-по-феншую» будет еще длиннее чем указано у Вас по моему простенькому скрипту )))

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

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