Чим більше я використовую, rsyncтим більше розумію, що це швейцарський армійський ніж передачі файлів. Варіантів дуже багато. Нещодавно я дізнався, що ви можете перейти, --remove-source-filesі він видалить файл із джерела, коли він буде скопійований, що робить його трохи більше, ніж крок копіювання програми. :)
Які ваші улюблені маленькі поради та рекомендації щодо rsync?
Відповіді:
Спробуйте використовувати rsync версії 3, якщо вам доведеться синхронізувати багато файлів! V3 нарощує свій список файлів поступово і набагато швидше і використовує менше пам'яті, ніж версія 2.
Залежно від вашої платформи, це може дуже змінити ситуацію. На OSX версії 2.6.3 пішло б більше години або збилося, намагаючись зібрати індекс у 5 мільйонів файлів, тоді як версія 3.0.2, яку я склав, почала копіювати відразу.
Використовується --link-destдля створення резервних копій на основі знімків з використанням простору, в результаті чого, здається, у вас є декілька повних копій даних резервної копії (по одній для кожного запуску резервної копії), але файли, які не змінюються між прогонами, жорстко пов'язані замість створення нових копій, економлячи місце.
(насправді я все ще використовую метод rysnc-наступний заcp -al методом, який досягає того самого, див. http://www.mikerubel.org/computers/rsync_snapshots/ для старого, але все ще дуже хорошого запуску обох методів та пов'язані з цим проблеми)
Основним недоліком цієї методики є те, що якщо файл пошкоджений через помилку диска, він настільки ж пошкоджений у всіх знімках, що посилаються на цей файл, але у мене є також резервні копії в режимі офлайн, які захищали б це проти цього в пристойній мірі. Інша річ, на яку слід звернути увагу, - це те, що у вашій файловій системі є достатньо входів, або у вас вичерпається їх, перш ніж у вас фактично не вистачить місця на диску (хоча у мене ніколи не було проблем із типовими налаштуваннями ext2 / 3).
Крім того, ніколи не забувайте про дуже корисну --dry-runдля трохи здорової параної, особливо коли ви використовуєте --delete*варіанти.
Якщо вам потрібно оновити веб-сайт із кількома величезними файлами через повільне посилання, ви можете перенести невеликі файли таким чином:
rsync -a - max-size = 100K / var / www / there: / var / www /
тоді зробіть це для великих файлів:
rsync -a --min-size = 100K --bwlimit = 100 / var / www / there: / var / www /
rsync має безліч варіантів, зручних для веб-сайтів. На жаль, у нього немає вбудованого способу виявлення одночасних оновлень, тому вам доведеться додавати логіку до сценаріїв cron, щоб уникнути перекриття записів величезних файлів.
--rsh моє.
Я використовував його для зміни шифру на ssh на щось швидше ( --rsh="ssh -c arcfour"), а також для створення ланцюжка sshs (рекомендую використовувати його ssh-agent) для синхронізації файлів між хостами, які не можуть безпосередньо говорити. ( rsync -av --rsh="ssh -TA userA@hostA ssh -TA -l userB" /tmp/foobar/ hostB:/tmp/foobar/).
--time-limit
При використанні цієї опції rsync припиниться через T хвилини і вийде. Я думаю, що цей варіант корисний, коли rsyncing великої кількості даних протягом ночі (не зайняті години), а потім зупинки, коли настав час люди почати користуватися мережею, протягом дня (зайняті години).
--stop-at=y-m-dTh:m
Цей параметр дозволяє вказати, на який час зупинити rsync.
Batch Mode
Пакетний режим можна використовувати для застосування одного і того ж набору оновлень до багатьох однакових систем.
atвбиваєш процес?
Якщо вам цікаво, як далеко дісталася повільна функція rsync, і ви не використовували -v для переліку файлів під час їх передачі, ви можете дізнатися, які файли у нього відкриті:
ls -l /proc/$(pidof rsync)/fd/*
на системі, яка має / проц
Напр. Rsync для мене вішали саме зараз, навіть незважаючи на те, що у віддаленій системі залишилось купу місця. Цей трюк допоміг мені знайти несподівано величезний файл, який я не запам’ятав, який не підходив би з іншого боку.
Це також розповіло мені трохи цікавішу інформацію - інший кінець, мабуть, здався, оскільки там також було пошкоджене сокетне посилання:
/proc/22954/fd/4: broken symbolic link to `socket:[2387837]'
--archive є стандартним вибором (хоча і не за замовчуванням) для резервних завдань, завдяки чому більшість метаданих із вихідних файлів (дозволи, право власності тощо) копіюються впоперек.
Однак, якщо ви не хочете використовувати це, часто ви все одно хочете включити --times, яке буде копіювати протягом часу модифікації файлів. Це робить наступний rsync, який запускається (припускаючи, що ви робите це повторно) набагато швидше, оскільки rsync порівнює моменти модифікації та пропускає файл, якщо він не змінюється. Дивно (щонайменше, для мене) цей варіант не є типовим.
--backup-dir = date +%Y.%m.%d--delete Ми видаляємо, але робимо копію ... про всяк випадок
Моя є --inplace. Чинить чудеса, коли на сервері для резервного копіювання працює ZFS або btrfs, і ви робите нативні знімки.
cwrsync - Rsync для Windows http://www.itefix.no/i2/node/10650
Ця версія включає OpenSSH, щоб ви могли переводити файли через захищений канал.
--partial
У разі перебоїв
--bwlimit=100
Для обмеження пропускної здатності - добре для копіювання великих файлів, каталогів
bwlimit? біт на секунду, байт на секунду?
коли я використовую GlusterFs, у нас є вузьке місце з T-файлами з нульовим розміром, для синхронізації між розбитою цеглою або репліками ми повинні використовувати, --min-size=1щоб не синхронізувати порожній файл з розбитого сервера
--delete-beforeнаприклад,), використовується стара поведінка "спочатку зібрати список", оскільки це потрібно, щоб ці параметри працювали правильно, тому якщо ви не бачите цієї поведінки, перевірте, чи відомі інші варіанти, які ви використовуєте, щоб зупинити це неможливо. Це може бути корисно, якщо ви використовуєте rsync інтерактивно на великому дереві та хочете примусити початкове сканування, щоб результат--progressбув точним (тобто кількість "об'єктів для порівняння" ніколи не зростатиме, оскільки нових об'єктів після початкового сканування не буде знайдено) ).