Как применить rsync к выполнению контрольной суммы?

Мы выполняем ночное резервное копирование файлового сервера Windows, сначала создавая файл инкрементного резервного копирования на сервере каждую ночь (а также полное резервное копирование в четверг вечером), а затем копируем его на резервный сервер под управлением Linux/Ubuntu. Чтобы сохранить избыточность вне сайта, мы затем rsync каталог резервного копирования на внешний диск, который вращается после каждого ночного запуска.

Со временем количество файлов инкрементной резервной копии постоянно увеличивалось (хотя размер этих файлов менялся).

Мы также заметили, что процесс 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 часа, чтобы определить метку времени и размер файла?

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

Источник

2 ответа

Решение

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