Как предотвратить создание __ MACOSX при извлечении архива, созданного на MacOS?

Отказ от ответственности: поскольку я никогда не использовал zvols, я не могу сказать, отличаются ли они в репликации от обычных файловых систем или снимков. Я предполагаю, что да, но не верю мне на слово.

На самом деле ваш вопрос состоит из нескольких вопросов, я пытаюсь ответить на них по отдельности:

Как реплицировать / зеркалировать полный пул в удаленное место

Вам нужно разделить задачу на две части: во-первых, начальная репликация должна быть завершенным, впоследствии возможна инкрементная репликация , если вы не вмешиваетесь в свои моментальные снимки репликации . Чтобы включить инкрементную репликацию, вам необходимо сохранить последние снимки репликации, все, что было до этого, можно удалить. Если вы удалите предыдущий снимок, 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 со слабым / отсутствующим шифрованием и отключенным сжатием, , что подробно описано в re . Также был веб-сайт о перекомпоновке SSH, чтобы он работал намного быстрее, но, к сожалению, я не помню URL-адрес - я отредактирую его позже, если найду его.

Для очень больших наборов данных и медленных соединений может также оказаться полезным первая передача через жесткий диск (используйте зашифрованный диск для хранения zpool и передачи его в запечатанном пакете курьером, почтой или лично). Поскольку метод передачи не имеет значения для send / recv, вы можете передать все по конвейеру на диск, экспортировать пул, отправить диск по назначению, импортировать пул, а затем передать все инкрементные отправки через SSH.

Проблема с испорченными снимками

Как было сказано ранее, если вы удалите / измените свои снимки репликации, вы получите сообщение об ошибке

cannot send 'pool/fs@name': not an earlier snapshot from the same fs

, которое означает, что либо ваша команда была неправильной, либо вы находитесь в несогласованном состоянии, в котором вы надо удалить снимки и начать все сначала.

Это имеет несколько отрицательных последствий:

1. Нельзя удалить моментальный снимок репликации, пока новый моментальный снимок репликации не будет успешно перенесен. Поскольку эти снимки репликации включают состояние всех других (более старых) снимков, пустое пространство удаленных файлов и снимков будет восстановлено только после завершения репликации. Это может привести к временным или постоянным проблемам с пространством в вашем пуле, которые вы можете исправить, только перезапустив или завершив полную процедуру репликации.
2. У вас будет много дополнительных снимков, что замедлит выполнение команды list (кроме Oracle Solaris 11, где это было исправлено).
3. Возможно, вам потребуется защитить снимки от (случайного) удаления, за исключением самого сценария.

Существует возможное решение этих проблем, но я сам его не пробовал.Вы можете использовать закладку zfs , новую функцию в OpenSolaris / illumos, созданную специально для этой задачи. Это освободит вас от управления снимками. Единственным недостатком является то, что в настоящее время он работает только для отдельных наборов данных, а не рекурсивно. Вам нужно будет сохранить список всех ваших старых и новых наборов данных, а затем перебрать их,создание закладок, их отправка и получение, а затем обновление списка (или небольшой базы данных, если хотите).

Если вы попробуете использовать закладку, мне было бы интересно узнать, как это сработало для вас!