Битва в облаках: тестируем скорость популярных хранилищ с помощью Rclone / Хабр

Всю глубину мудрости людей, пропагандирующих регулярное резервное копирование, осознаёшь, только когда у тебя накрылся очередной 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-файлы нейросетке и попросил свести усредненные результаты тестов в единую табличку. Вот что получилось в итоге:

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

Remote	Upload (sec)	Delay (sec)	Download (sec)	Total (sec)
yandex	304.643342	2.891870	269.468760	577.003973
dropbox	312.658847	3.302507	288.230279	604.191632
mailru	306.867160	2.728859	309.806713	619.402732
google	338.554430	3.096721	294.370987	636.022138
onedrive	393.920261	3.480811	368.866466	766.267539

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

Сравнительный график загрузки и выгрузки тестового файла

По итогам усреднённых тестов лучше всех показал себя Яндекс Диск: суммарное время загрузки, задержки появления и скачивания файла у него составило около 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"

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

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

Remote	Upload (sec)	Delay (sec)	Download (sec)	Total (sec)
yandex	290.02	3.06	207.10	500.18
dropbox	306.45	4.10	243.19	553.74
google	310.54	3.07	240.31	553.92
mailru	325.99	3.38	268.72	598.09
onedrive	306.33	3.43	348.31	658.07

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

Сравнительный график загрузки и выгрузки тестового файла в macOS

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

Выводы

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

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

Битва в облаках: тестируем скорость популярных хранилищ с помощью Rclone