Всю глубину мудрости людей, пропагандирующих регулярное резервное копирование, осознаёшь, только когда у тебя накрылся очередной SSD с важными данными. В этот момент сразу перестаёшь обсуждать теорию информационной безопасности и начинаешь мыслить исключительно в прагматичном ключе: что попытаться спасти в первую очередь и как не допустить подобной ситуации в будущем. Привычка копировать самые ценные файлы на внешние носители и домашний файловый сервер у меня выработалась ещё в эпоху массового распространения троянов-шифровальщиков, но делалось это вручную и нерегулярно. Я, конечно, собирался автоматизировать процесс, но сначала было некогда, а потом стало лень. И вот на днях, когда диск моего рабочего ноутбука внезапно помахал мне ладошкой и отправился в вечный отпуск без обратного билета, настало время раз и навсегда закрыть этот гештальт. Или гешефт. Вечно их путаю.

Одно дело осознать, что автоматизированный бэкап необходим, как гаишнику — фуражка, совсем другое — решить, куда именно складывать эти самые бэкапы. На внешний диск? Хорошо, пока не забыл его дома или пока он не решит отправиться на заслуженный отдых вслед за системным SSD. Домашний сервер — тоже неплохой вариант, если не лень возиться с настройками доступа к файлам из внешнего интернета и решать сопутствующие проблемы с безопасностью. Рано или поздно в голову закрадывается мысль, что самый оптимальный и наименее трудозатратный метод — использовать бесплатные облачные хранилища. Только вот облаков нынче — как в осеннем небе над Питером, их скорость работы и возможности довольно сильно отличаются. И если для копирования парочки фотографий с новогоднего корпоратива это не критично, то при работе с большими файлами вроде архива рабочих папок разница уже ощущается физически. Как понять, в каком облаке удобнее хранить объемные файлы и где они будут синхронизироваться быстрее всего? Чтобы найти ответ, я решил протестировать несколько популярных облачных хранилищ и сравнить результаты. Полученной информацией я и поделюсь сегодня с вами: надеюсь, это поможет кому-то сэкономить время и нервы.

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

Почему Rclone?

Rclone — это кроссплатформенная консольная утилита с открытым исходным кодом, поддерживающая Windows, macOS и Linux. В отличие от «официальных клиентов» облачных провайдеров, Rclone использует единый набор команд для доступа к различным сервисам — от популярных вроде Google Drive и Dropbox, до S3-совместимых или корпоративных хранилищ с WebDAV. Главное достоинство утилиты состоит в том, что она умеет выполнять необходимый базовый набор операций: синхронизировать данные, зеркалить каталоги, монтировать удалённое хранилище как локальный диск и вообще делает всё то, что обычно приходится собирать из кучи отдельных инструментов.

Для тестов это означает одинаковые условия: если я выполняю команду rclone copy, то во всех случаях используется один и тот же алгоритм передачи данных, и никакие «фишки» конкретного клиента не искажают результаты. А ещё, помимо прозрачности, Rclone обеспечивает необходимый контроль. Утилита позволяет наблюдать за процессом копирования в реальном времени, получать отчёты о скорости передачи данных и объёме загруженных файлов, включать отладочный вывод для анализа ошибок и сравнивать хэши после загрузки. В контексте эксперимента это особенно важно: можно опираться не на субъективные ощущения из разряда «кажется, Google Drive грузит быстрее», а на конкретные цифры, которые фиксируются самим инструментом.

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

Условия эксперимента

Для сравнения я взял пять популярных облачных хранилищ: Облако Mail.ru, Google Drive, Яндекс Диск, Dropbox и OneDrive. Все они имеют собственные программы-клиенты, но для чистоты замеров использовался только Rclone, чтобы исключить влияние различий в интерфейсе и внутренней логике фирменных приложений. Таким образом, сервисы оказались в равных условиях: одни и те же команды, один и тот же сценарий, никаких оптимизаций, доступных лишь «родному» ПО.

Основным объектом испытаний стал тестовый файл размером 1 ГБайт. Такой объём достаточно велик, чтобы проявились особенности работы каждого облака, и в то же время не слишком тяжёл, чтобы тесты можно было повторять многократно. Файл не содержал реальных данных — он генерировался средствами самой операционной системы. В Windows для этого использовалась команда fsutil file createnew, а в macOS — dd if=/dev/urandom of=testfile bs=1m count=1024. Такой подход позволил создать «чистые» болванки без расширений и метаданных, которые могли бы повлиять на обработку или индексацию в облаке.

Тестирование проводилось в двух ОС — Windows 10 Pro 22H2 и macOS Catalina. На каждой платформе замеры выполнялись в одинаковых условиях: домашнее подключение к интернету без VPN и прокси, с использованием одной и той же команды rclone copy. Фиксировались три параметра: время загрузки файла, момент появления его в интерфейсе облака (то есть фактическая доступность для скачивания) и скорость обратной загрузки на локальную машину.

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

Участники эксперимента

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

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

• Яндекс Диск. Поддерживает полноценный REST API, Rclone работает с ним без ограничений. Скорость в основном упирается в пропускную способность сети и размер файла. Из особенностей стоит отметить лимиты на количество параллельных запросов, но при последовательной передаче крупных файлов они практически не сказываются.

• Облако Mail.ru. API официально не документировано, интеграция в Rclone реализована методами «обратной инженерии». В результате сервис иногда ведёт себя менее предсказуемо: возможны временные задержки в обработке загруженного файла, а также ограничения на количество одновременных потоков.

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

• OneDrive. API поддерживает возобновляемые и многопоточные загрузки, что позволяет эффективно работать с крупными файлами. Основное ограничение связано с проверкой загруженного контента: до завершения индексации файл может быть недоступен для скачивания, хотя сам аплоад уже окончен. На практике это приводит к дополнительной задержке между «файл загрузился» и «файл можно скачать».

Итак, участники расставлены по местам, правила оговорены, а файлы уже ждут своей очереди. Впереди — самое интересное.

Эксперимент

Microsoft Windows

Итак, для начала я создал пустой файл объемом 1 Гбайт с использованием команды fsutil file createnew testfile 1073741824 и зарегистрировал новые аккаунты в каждом из тестируемых облачных сервисов. С установкой и конфигурацией Rclone серьёзных проблем не возникло, если не считать настройку утилиты на работу с облаком Mail.ru — нормальной инструкции для этого хранилища нет, мануал, опубликованный на сайте rclone.org, не работает, утилита с разными параметрами выдает ошибки, и что с этим делать, непонятно. Я провозился с конфигурацией хранилища битых три часа, справившись со всеми остальными облаками буквально за пару минут, и добил его из чистого упрямства. Причем подключить в конечном итоге удалось не стандартное «Облако», доступное по адресу cloud.mail.ru (оно так и не заработало), а специально созданный бакет в VK Cloud (https://cloud.vk.com), для чего пришлось изрядно поплясать с бубном. Предварительный вывод таков: Mail.ru и VK Cloud для работы с Rclone не предназначены вообще. Все второстепенные параметры удаленных хостов в Rclone я оставил со значениями по умолчанию.

Чтобы автоматизировать процесс, я написал следующий скрипт для Power Shell (для его нормальной работы пришлось включить в системе по умолчанию запрещенный запуск сценариев PS для текущего окна командой Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass):

# Список облаков (имена remote из rclone config)
$Remotes = @("yandex:", "dropbox:", "onedrive:", "google:", "mailru:")
 
# Имя тестового файла
$FileName   = "testfile"
$LocalPath  = "C:\test\$FileName"
 
# Файл для сохранения результатов
$ResultCsv = "C:\test\rclone_results.csv"
 
# Заголовок CSV
"Remote,UploadTimeSec,CloudDelaySec,DownloadTimeSec" | Out-File -Encoding UTF8 $ResultCsv
 
foreach ($Remote in $Remotes) {
    Write-Host "==============================="
    Write-Host "Testing remote: $Remote"
    Write-Host "==============================="
 
    $RemotePath = "$Remote/test_rclone"
 
	# --- 1. Upload ---
    $UploadStart = Get-Date
    rclone copy $LocalPath $RemotePath --stats=1s --stats-one-line
	$UploadEnd = Get-Date
 
	# --- 2. Ждём появления файла в облаке ---
	do {
        Start-Sleep -Seconds 2
        $exists = rclone ls $RemotePath | Select-String $FileName
	} until ($exists)
 
    $CloudAvailable = Get-Date
 
	# --- 3. Download ---
    $DownloadStart = Get-Date
    rclone copy "$RemotePath/$FileName" "C:\Temp\downloaded_$($Remote.TrimEnd(':'))_$FileName" --stats=1s --stats-one-line
    $DownloadEnd = Get-Date
 
	# --- 4. Подсчёт ---
    $UploadDuration   = ($UploadEnd - $UploadStart).TotalSeconds
    $CloudDelay   	= ($CloudAvailable - $UploadEnd).TotalSeconds
    $DownloadDuration = ($DownloadEnd - $DownloadStart).TotalSeconds
 
    Write-Host "Upload:   $UploadDuration sec"
    Write-Host "Delay:    $CloudDelay sec"
    Write-Host "Download: $DownloadDuration sec"
 
	# --- 5. Запись в CSV ---
    "$Remote,$UploadDuration,$CloudDelay,$DownloadDuration" | Out-File -Append -Encoding UTF8 $ResultCsv
}
 
Write-Host "`n All tests are complete. Results are saved to $ResultCsv"

Скрипт работает очень просто, но при этом даёт наглядное представление о том, как ведут себя разные облачные хранилища. Сначала он фиксирует момент начала загрузки файла и запускает команду rclone copy, которая отправляет тестовый файл в облако. Когда передача завершается, отмечается время окончания — именно этот интервал и показывает, сколько секунд заняла загрузка.

На этом работа не прекращается. Облачные сервисы не всегда делают файл мгновенно доступным: иногда он появляется в интерфейсе чуть позже, после внутренней обработки. Чтобы отследить этот момент, скрипт регулярно опрашивает облако командой rclone ls. Как только файл появляется в списке, фиксируется новая временная отметка. Разница между концом загрузки и этим моментом отражает задержку индексации — своеобразное «ожидание у дверей», когда файл уже закачан, но ещё недоступен для пользователя.

Затем наступает обратная фаза — скачивание. Скрипт снова запускает rclone copy, но теперь из облака на локальный компьютер, и снова отмечает время старта и завершения. Так получается ещё одно измерение — скорость загрузки в обратную сторону.

Все эти данные аккуратно складываются в CSV-файл: название облака, время загрузки, задержка появления и длительность скачивания. Такой журнал легко открыть в Excel или LibreOffice и сравнить результаты между разными сервисами. Получается небольшая лаборатория, которая показывает весь жизненный цикл файла — от отправки и «ожидания в облаке» до возвращения назад, с точными цифрами на каждом этапе.

В Windows я запускал скрипт дважды, в промежутке между запусками удалив файл из хранилищ и скачанные копии — с локального диска.

Я скормил получившиеся CSV-файлы нейросетке и попросил свести усредненные результаты тестов в единую табличку. Вот что получилось в итоге:

Усредненные результаты тестов

А вот скорость загрузки и закачки на наглядном графике:

По итогам усреднённых тестов лучше всех показал себя Яндекс Диск: суммарное время загрузки, задержки появления и скачивания файла у него составило около 577 секунд, что заметно меньше, чем у конкурентов. Чуть медленнее оказался Dropbox — его совокупный результат превысил 600 секунд, но при этом он показал одну из лучших скоростей скачивания. Mail.ru, несмотря на весьма шустрый аплоад и минимальные задержки, проиграл на этапе загрузки файла обратно на компьютер, и в итоге суммарное время составило порядка шестисот девятнадцати секунд. Google Диск держится на среднем уровне: около 636 секунд в сумме, с неплохим балансом между загрузкой и скачиванием, но без рекордов. Аутсайдером стал OneDrive — почти 766 секунд, что связано с самой медленной скоростью аплоада и ощутимо долгой загрузкой тестового файла.

Время появления файла в доступе после закачки у всех сервисов укладывается в 3,5 секунды, при этом Mail.ru справляется с этой задачей чуть быстрее остальных. Небольшие колебания скорости теоретически можно списать на джиттер сети, тем более, дома у меня достаточно хороший канал, и на время тестирования я отключил от интернета все остальные устройства. Поэтому я не удержался, и еще раз прогнал тест в нашей редакционной локалке, нагруженной трафиком множества пользователей. Этот замер я проводил уже без Mail.ru — конфигурационный файл Rclone я забыл дома, а проходить еще раз весь этот увлекательный квест по многоступенчатой настройке хранилища мне было ужасно лень. Здесь разница еще более ощутима.

macOS

В macOS я решил немного облегчить себе задачу, и после установки Rclone просто скопировал с Windows-хоста файл конфигурации rclone.conf с уже настроенным доступом к хранилищам (узнать текущее местоположение этого файла можно с помощью команды rclone config file). Для этой системы был написан другой сценарий с аналогичным принципом действия:

#!/bin/bash

# === Настройки ===
REMOTES=("yandex:" "dropbox:" "onedrive:" "google:" "mailru:")   # список rclone remote
FILENAME="testfile.bin"                 # тестовый файл
LOCALPATH="$HOME/$FILENAME"             # путь к файлу
RESULTCSV="$HOME/results.csv"    # файл для результатов

# Заголовок CSV
echo "Remote,UploadTimeSec,CloudDelaySec,DownloadTimeSec" > "$RESULTCSV"

for REMOTE in "${REMOTES[@]}"; do
    echo "==============================="
    echo "Testing remote: $REMOTE"
    echo "==============================="

    REMOTEPATH="${REMOTE}test_rclone"

    # --- Upload ---
    UPLOAD_START=$(date +%s)
    rclone copy "$LOCALPATH" "$REMOTEPATH" --stats=1s --stats-one-line
    UPLOAD_END=$(date +%s)

    # --- Ждем появления в облаке ---
    while true; do
        sleep 2
        if rclone ls "$REMOTEPATH" | grep -q "$FILENAME"; then
            CLOUD_AVAILABLE=$(date +%s)
            break
        fi
    done

    # --- Download ---
    DOWNLOAD_START=$(date +%s)
    rclone copy "$REMOTEPATH/$FILENAME" "$HOME/downloaded_${REMOTE%%:*}_$FILENAME" --stats=1s --stats-one-line
    DOWNLOAD_END=$(date +%s)

    # --- Подсчет ---
    UPLOAD_DURATION=$((UPLOAD_END - UPLOAD_START))
    CLOUD_DELAY=$((CLOUD_AVAILABLE - UPLOAD_END))
    DOWNLOAD_DURATION=$((DOWNLOAD_END - DOWNLOAD_START))

    echo "Upload:   $UPLOAD_DURATION sec"
    echo "Delay:    $CLOUD_DELAY sec"
    echo "Download: $DOWNLOAD_DURATION sec"

    # --- Сохранение в CSV ---
    echo "$REMOTE,$UPLOAD_DURATION,$CLOUD_DELAY,$DOWNLOAD_DURATION" >> "$RESULTCSV"
done

echo ""
echo "All tests completed. Results saved in results.csv"

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

Усредненные результаты тестов

А вот усредненный график результатов для macOS:

Здесь тоже без сюрпризов: Яндекс Диск показывает лучшую общую производительность, особенно за счет быстрого скачивания, в то время как OneDrive демонстрирует самые медленные результаты, главным образом из-за долгого времени обратной загрузки. Mail.ru в этом тесте почему-то выдал наиболее продолжительное время закачки, а Dropbox и Google Drive показали схожие результаты.

Выводы

По результатам эксперимента лично для себя я сделал следующие выводы. Из всех протестированных хранилищ, несмотря на довольно приличные результаты, я исключил Mail.ru — из-за плохой поддержки Rclone, сложности настройки и полнейшего отсутствия понятных инструкций, объясняющих, как со всем этим бороться. Также из числа победителей выпал OneDrive — в силу низкой скорости, которая может стать проблемой при загрузке большого количества файлов. Среди оставшихся трех сервисов хуже всех выглядит Dropbox, но не благодаря неважным показателям, а из-за ограниченного объема хранилища: бесплатно предоставляется всего лишь 2 Гбайта против 5 Гбайт у Яндекс Диска и 15 у Google Drive, которые делятся между Gmail, Google Фото и самим Диском. При этом скоростные характеристики эти два облака демонстрируют схожие — Яндекс Диск работает чуть быстрее, но в целом это компенсируется большим объемом доступного пространства у Google.

Идеального облачного решения не существует — у каждого есть свои сильные и слабые стороны. В итоге я настроил автоматическое резервное копирование на оба сервиса: наиболее критичные данные синхронизируются с Яндекс Диском благодаря его высокой скорости, а менее приоритетные файлы отправляются на Google Drive, где имеется достаточно места для долгосрочного хранения. Такой подход позволяет получить лучшее от обоих миров — скорость и объём — при минимальных рисках потери данных.