Мы выполняем ночное резервное копирование файлового сервера Windows, сначала создавая инкрементный файл резервной копии на сервере каждую ночь (а также полную резервную копию в четверг вечером), а затем копируя его на резервный сервер под управлением Linux / Ubuntu. Чтобы поддерживать внешнюю избыточность, мы затем синхронизируем каталог резервных копий с внешним диском, который меняется после каждого ночного запуска.
Со временем количество файлов инкрементных резервных копий неуклонно увеличивалось (хотя размер этих файлов менялся).
Мы также заметили, что процесс rsync постоянно занимает больше времени, даже если он копирует только два последних файла на внешний диск.
Это команда:
rsync -vr --delete-before --log-file=/rsync_log.csv /backup/archive/ /mnt/usbdisk/ 2>&1
Когда мы протестировали команду и исследовали файл журнала, мы увидели следующее:
...
2011/02/14 23:59:35 [14054] >f..T...... IncrementalBackup_2011_02_06_20.bkf
2011/02/15 00:00:45 [14054] >f..T...... IncrementalBackup_2011_02_08_20.bkf
2011/02/15 00:03:22 [14054] >f..T...... IncrementalBackup_2011_02_09_20.bkf
2011/02/15 00:04:36 [14054] >f..T...... IncrementalBackup_2011_02_11_20.bkf
2011/02/15 00:04:51 [14054] >f..T...... IncrementalBackup_2011_02_12_20.bkf
2011/02/15 00:05:06 [14054] >f..T...... IncrementalBackup_2011_02_13_20.bkf
2011/02/15 00:06:13 [14054] >f+++++++++ IncrementalBackup_2011_02_14_20.bkf
2011/02/15 00:54:32 [14054] >f..T...... Thursday_Full_Backup_2011_01_20.bkf
2011/02/15 03:24:41 [14054] >f..T...... Thursday_Full_Backup_2011_01_27.bkf
...
Мы обнаружили время, затраченное на каждый файл, связанное с размером файла - даже при его пропуске (например, полная резервная копия заняла около 2,5 часов, а инкрементная - около 2-3 минут или меньше).
Единственный фактически скопированный файл - это последний инкрементный файл.
Единственное объяснение, которое мы можем придумать, - это то, что rysnc выполняет контрольную сумму файла - хотя в документации сказано, что это не так по умолчанию, и мы не указали переключатель --checksum в команде. Неужто не может потребоваться 2,5 часа, чтобы определить метку времени и размер файла?
После просмотра документации я не нашел другого объяснения, кроме вычисления контрольной суммы. Итак, есть ли способ убедиться, что контрольная сумма отключена?
Возможно, проблема в метках времени файлов. Если резервные копии создаются с помощью программы Windows, это может испортить временные метки. Если я воспроизведу ваш образец с кучей изображений, я получу этот журнал
2011/02/15 03:46:46 [61820] delta-transmission disabled for local transfer or --whole-file
2011/02/15 03:46:46 [61820] .d..t....... ./
2011/02/15 03:46:46 [61820] IMG_0055.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0056.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0057.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0058.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0059.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0060.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0061.JPG is uptodate
2011/02/15 03:46:46 [61820] >f..t....... IMG_0062.JPG
2011/02/15 03:46:46 [61820] IMG_0063.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0064.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0065.JPG is uptodate
2011/02/15 03:46:46 [61820] IMG_0066.JPG is uptodate
2011/02/15 03:46:46 [61820] total: matches=0 hash_hits=0 false_alarms=0 data=5911343
2011/02/15 03:46:46 [61820] sent 5912367 bytes received 67 bytes 11824868.00 bytes/sec
2011/02/15 03:46:46 [61820] total size is 75450221 speedup is 12.76
Таким образом, файлы передаются каждый раз, иначе у вас должно быть сообщение журнала file xxx is uptodate. Попробуйте увеличить подробность rsync с помощью более чем одного флага v, чтобы узнать, что происходит.
Какая файловая система представляет собой USB-накопитель?
Проблема с FAT и временными метками. См. Справочную страницу rsync:
--modify-window
When comparing two timestamps, rsync treats the timestamps as being equal if they differ by no more
than the modify-window value. This is normally 0 (for an exact match), but you may find it useful to
set this to a larger value in some situations. In particular, when transferring to or from an MS Win‐
dows FAT filesystem (which represents times with a 2-second resolution), --modify-window=1 is useful
(allowing times to differ by up to 1 second).