Відмова: Оскільки я ніколи не використовував дзвінки, я не можу сказати, чи відрізняються вони у тиражуванні, ніж звичайні файлові системи чи знімки. Я припускаю, що вони є, але не приймайте за це мого слова.
Насправді у вас багато запитань, я намагаюся відповісти на них окремо:
Як копіювати / дзеркально завершувати басейн у віддалене місце
Потрібно розділити завдання на дві частини: по-перше, початкова реплікація повинна бути завершеною, згодом можлива інкрементальна реплікація, доки ви не зіпсуєтесь зі своїми знімками реплікації . Щоб увімкнути поступову реплікацію, вам потрібно зберегти останні знімки реплікації, все до цього можна видалити. Якщо ви видалите попередній знімок, zfs recvбуде скаржитися і скасовувати реплікацію. У цьому випадку вам доведеться починати все заново, тому намагайтеся цього не робити.
Якщо вам просто потрібні правильні варіанти, вони є:
zfs send:
-R: надсилайте все під заданий пул або набір даних (рекурсивна реплікація, необхідна весь час, включає -p). Також при отриманні всі видалені знімки джерела видаляються у пункті призначення.-I: включити всі проміжні знімки між останнім знімком реплікації та поточним знімком реплікації (потрібні лише при поступових надсиланнях)
zfs recv:
-F: розширити цільовий пул, включаючи видалення існуючих наборів даних, які видаляються з джерела-d: відкиньте ім'я вихідного пулу та замініть його назвою пулу призначення (решта шляхів файлової системи будуть збережені, а за потреби також створені)-u: не монтуйте файлову систему за призначенням
Якщо ви віддаєте перевагу повний приклад, ось невеликий сценарій:
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
Використовуйте щось швидше, ніж SSH
Якщо у вас є достатньо захищене з'єднання, наприклад, IPSec або тунель OpenVPN і окремий VLAN, який існує лише між відправником і одержувачем, ви можете перейти з SSH на незашифровані альтернативи, такі як mbuffer, як описано тут , або ви можете використовувати SSH зі слабким / відсутнім шифруванням та відключене стиснення, про що тут докладно . Також був веб-сайт про те, як передати SSH набагато швидше, але, на жаль, я не пам'ятаю URL-адресу - я відредагую її пізніше, якщо знайду.
Для дуже великих наборів даних і повільних з’єднань може бути корисним також перша передача через жорсткий диск (використовуйте зашифрований диск для зберігання zpool та передачі його в герметичному пакеті кур'єром, поштою або особисто). Оскільки спосіб передачі не має значення для send / recv, ви можете передавати все на диск, експортувати пул, відправляти диск до місця призначення, імпортувати пул, а потім передавати всі додаткові надсилання через SSH.
Проблема зі змішаними знімками
Як було сказано раніше, якщо ви видалите / зміните знімки реплікації, ви отримаєте повідомлення про помилку
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
що означає, що або ваша команда була неправильною, або ви перебуваєте в непослідовному стані, коли потрібно видалити знімки і почати все спочатку.
Це має кілька негативних наслідків:
- Ви не можете видалити знімок реплікації, поки успішно не буде передано новий знімок реплікації. Оскільки ці знімки реплікації включають стан усіх інших (старіших) знімків, порожній простір видалених файлів та знімків буде відновлено лише у тому випадку, якщо реплікація закінчиться. Це може призвести до тимчасових або постійних проблем з простором у вашому пулі, які ви зможете виправити, лише перезапустивши або закінчивши повну процедуру реплікації.
- У вас буде багато додаткових знімків, що уповільнює команду списку (за винятком Oracle Solaris 11, де це було виправлено).
- Можливо, вам потрібно буде захистити знімки від (випадкового) видалення, за винятком самого сценарію.
Існує можливе рішення цих проблем, але я сам цього не пробував. Ви можете використовувати zfs bookmarkнову функцію в OpenSolaris / illos, створену спеціально для цього завдання. Це звільнить вас від управління знімками. Єдиний мінус полягає в тому, що в даний час він працює лише для окремих наборів даних, а не рекурсивно. Вам потрібно буде зберегти список усіх своїх старих і нових наборів даних, а потім провести циклічну передачу над ними, робити закладки, надсилати та отримувати їх, а потім оновлювати список (або невелику базу даних, якщо вам зручніше).
Якщо ви спробуєте маршрут закладок, мені було б цікаво почути, як це у вас вийшло!
zfs send -R ...? Якщо ви переводили вихід черезssh, ви відключили символи втечіzfs send -R ... | ssh -e none ...?