Какие ежедневные команды мне нужно использовать для выполнения вышесказанного? (Практически любое руководство в Интернете связано с NAS и RAID или клонируется через SSH)
Нет реальной разницы между копированием по сети вместо локального копирования - вместо zfs send | ssh zfs recv вас просто есть zfs send | zfs recv - или вы можете даже сохранить резервную копию в потоковой форме (без zfs recv и с некоторыми недостатками) и расширять ее только при необходимости.
Можно ли использовать ext4 для /home в сочетании с корневым ZFS?
Должен ли я отформатировать SDB4 как ZFS?
Какова ваша цель с разделом ext4? Вы можете сделать это таким образом, но вы упустите моментальные снимки и проверки целостности ваших пользовательских данных. На мой взгляд, любую систему можно вернуть дешево, но потерянные пользовательские данные будут потеряны навсегда. Если бы мне пришлось выбирать, я бы использовал ZFS для своих пользовательских данных и ext4 для (бесполезного) системного раздела, а не наоборот.
Может быть, есть совершенно другой подход к этому? (Обратите внимание, я хочу отдельный раздел для /home и запоминающее устройство с твердой обратной совместимостью, поэтому я выбрал здесь ext4)
- Если вы видите обратную совместимость как «Я хочу протестировать ZFS, а затем вернуться к ext4 без копирования данных», вы ничего не получите: вы не увидите преимуществ ZFS и сохраните недостатки ext4. Кроме того, у вас есть больше работы по созданию загрузочной системы ZFS в Linux (хотя вы уже делали это в этом случае), чем при настройке простого раздела данных для пользовательских данных с ZFS.
- Если вы видите это как "Я хочу получить к нему доступ с других систем", я бы предложил NFS, SMB, AFP или SSH (или все из них одновременно).
- Если это для двойной загрузки с системой, которая не поддерживает ZFS, это будет одно из немногих созвездий, где ваш макет имеет смысл.
- Если вы не доверяете ZFS для обеспечения безопасности ваших данных или не доверяете версии Linux, либо используйте Solaris/illumos/* BSD, либо сохраняйте резервные копии на ext4. Таким образом, вы теряете простую утилиту резервного копирования send/recv, но, по крайней мере, знаете, что вы резервируете только хорошие данные.
Начиная с вашего текущего описания, вы все еще можете достичь всех своих целей, но это будет неоптимальным и более сложным, чем вы обрисовали его.
Вместо этого подумайте об использовании ZFS на всех ваших дисках, возможно, добавив избыточность, если это возможно (это можно сделать позже, добавив зеркальный диск), используя файловые системы ZFS вместо разделов (для разделения проблем), и регулярно создавайте резервные копии снимков на различные диски (для борьбы с возможным повреждением из-за отсутствия памяти ECC).
Продолжение вашего комментария:
Не могли бы вы уточнить эту ситуацию в своем ответе и предоставить подробные сведения (как в структуре) об управлении снимками и о том, как выполнить загрузку одного из них или восстановить снимок с правами root? Я бы разделил целые 3 ТБ как ZFS, а затем из своей ОС ZFS добавил пулы данных и наборы данных для моего хранилища, домашнего раздела и снимка, я полагаю. Но оттуда я буду беспомощен.
Да, в значительной степени это. Я не знаю ваших аппаратных опций, но, если у вас есть диски, которые вы описали, я бы сделал следующее:
Настройка и макет
Расположение оборудования и бассейна
Обычно вы используете SSD в качестве кэша чтения, но на рабочем столе вы теряете все преимущества кэша L2ARC (за исключением Solaris 11.3, где он сохраняется и перезагружается).
Таким образом, вы можете либо поместить все на жесткий диск и использовать SSD в качестве устройства SLOG (только для записи с синхронизацией); или вы можете разделить их и поместить ваши системные данные (корневой пул) на SSD, а остальные - на HDD.
Теоретически, вы могли бы добиться более высокой производительности с первым решением, но я сомневаюсь, что ваша система остается в сети достаточно долго, чтобы заметить это. Таким образом, второе решение менее хлопотно, и ваш SSD проживет дольше.
Таким образом, вы создаете два пула - один корневой пул (предположим, что он называется rpool) на SSD с 250 ГБ и один пул data ( данные ) на жестком диске с 3000 ГБ. Оба не являются избыточными, потому что у них есть только 1 vdev каждый, но позже вы можете добавить дополнительный жесткий диск или твердотельный накопитель, чтобы сделать их зеркалами с zpool attach data /dev/<old_disk> /dev/<new_disk> (так что ошибки могут быть исправлено автоматически). Это необязательно, но рекомендуется (если вы можете добавить только один диск, добавьте зеркало данных, потому что ваши данные более ценны, чем система, которая в любом случае клонируется в data).
Вам не нужны никакие дополнительные разделы (кроме, может быть, разделов подкачки и / или загрузки, но это будет сделано автоматически при установке), потому что ваши файловые системы ZFS будут выполнять эту роль.
Структура файловой системы ZFS
Теперь у вас есть два пула - rpool уже заполнен (извините, я не могу здесь вдаваться в подробности, поскольку Linux отличается от illumos/Solaris) от вашей установки - вам не нужно ничего менять здесь. С помощью zfs mount вы можете проверить, правильно ли смонтированы файловые системы.
data другой стороны, данные все еще пусты, поэтому вы добавляете несколько файловых систем:
# zfs create data/home
# zfs create data/home/alice
# zfs create data/sysbackup
# zfs create data/pictures
...
Проверьте с помощью zfs mount если они смонтированы правильно, если нет, то смонтируйте их с помощью zfs mount (и / или в fstab, опять же, это может отличаться в Linux). Мне проще, если структура каталогов аналогична структуре файловой системы (но это не обязательно): /home/alice соответствует data/home/alice .
ACL и общий доступ к сети
Теперь было бы неплохо подумать о разрешениях и общих ресурсах (потому что оба они включены в ваши будущие моментальные снимки, так как они являются свойствами файловой системы моментальных снимков в определенный момент времени).
Все ваши файлы и каталоги будут иметь файловые ACL (списки контроля доступа). Кроме того, все ваши сетевые ресурсы Windows (SMB/CIFS) будут иметь общие списки управления доступом. Это широкая тема, но для настольной системы вы можете упростить ее: настройте файловые ACL-списки так, как вы хотите предоставить разрешения (используя только allow, no deny), и оставьте разрешения общего ресурса по умолчанию (у всех есть доступ). Поэтому они игнорируются, и вам просто нужно управлять одним набором разрешений, которые работают локально и для всех сетевых протоколов общего доступа (AFP, SMB, NFS).
Чтобы показать списки ACL, используйте ls -Vd /home/alice для самого каталога и ls -V /home/alice для всех файлов внутри. В зависимости от вашей системы ls может быть неправильной версией (GNU ls вместо Solaris ls), поэтому вам может понадобиться полный путь.
Чтобы изменить ACL, используйте chmod (так же, как со списком), хорошая документация здесь.
Также вы должны установить любые свойства ZFS в файловых системах (zfs get и zfs set), если это необходимо.
моментальные снимки
Фон на снимках
Каждый снимок - это просто атомарное сохраненное состояние данной файловой системы на момент создания. Это как машина времени, куда вы можете вернуться и посмотреть, как это было день или год назад. Они доступны только для чтения, поэтому вы не можете их изменять (только полностью удалять), и они занимают место только для измененных блоков с момента их создания.
Это означает, что каждый снимок начинается с (почти) нулевого размера байтов, а каждый измененный, добавленный или удаленный блок записывается и сохраняется, что означает, что моментальный снимок начинает расти (из-за свойства Copy-on-Write в ZFS).
Если вы представляете свои данные в строке слева направо (например, на временной шкале), новый блок записывается справа от последнего старого блока. Если вы установите снимок после блока 5, изначально ничего не изменится. Затем добавляется блок 6 справа, но в снимке по-прежнему есть ссылки только на блоки 0–5. Если блок 3 удален, пространство не освобождается до тех пор, пока снимок не будет уничтожен, поскольку он по-прежнему ссылается на блоки с 0 по 5. Модифицирующий блок 4 - это (CoW!) так же, как добавление блока 6 и перемещение ссылок после операции записи, но опять же, пробел не освобождается, потому что снимок все еще требует хранения исходных блоков от 0 до 5. Если мы окончательно уничтожим моментальный снимок, мы освободим блоки 4 и 5, что приведет к отверстию (фрагментации), которое позже может быть заполнено другими блоками.
Это уровень блоков, каждый файл может состоять из нескольких блоков по всему диску. На уровне файлов вы видите файлы в этой единственной точке в прошлом, как будто ничего не изменилось. Может быть полезно немного поиграть со снимками и добавить / редактировать / удалить простые текстовые файлы, чтобы вы почувствовали это. Идея довольно проста, но работает очень эффективно.
Автоматическое вращение снимка
IIRC, в Linux вы можете использовать zfs-auto-snapshot, чтобы сделать это автоматически, или вы можете настроить свои собственные скрипты, вызываемые cron через регулярные промежутки времени (для создания снимков и для их уничтожения).
Что касается хорошего вращения, это зависит от ваших моделей использования и потребностей. Я бы начал с щедрой суммы, чтобы вы могли уменьшить по мере необходимости. Удалить снимки легко, задним числом создать их невозможно. Если ваши показатели танков, уменьшите интервалы.
- Системные данные: для моментов "rm -rf /" и нежелательных / плохих обновлений, также для ошибок, которые появляются позже
- один раз в час, сохранить 12
- один раз в день, сохранить 7
- один раз в месяц, сохранить 12
- Персональные данные: пользовательские каталоги и сетевые ресурсы, по сути самые ценные данные
- каждые пять минут сохраняйте 12
- каждый час, сохраняйте 24
- каждый день сохраняйте 30
- каждый месяц удерживать 12
- каждый год сохраняйте 10
- Scrap data: для личных вещей, которые не должны распространяться по снимкам, для временных данных, для рабочих наборов данных, которые сильно изменяются, но бесполезны после перезагрузок
- Sysbackup: вам здесь не нужны снимки, потому что они уже есть в
rpool и они просто скопированы
Резервное копирование и восстановление
По сути, со временем ваши снимки накапливаются и обеспечивают скользящий просмотр ваших данных в течение определенного периода времени. Поскольку аппаратное обеспечение может и, скорее всего, выйдет из строя, вам необходимо выполнить резервное копирование этих данных на другой диск или систему. Если вы используете zfs send и zfs recv , ваши временные снимки, ACL и свойства сохраняются, а это означает, что резервная копия - это просто комбинация полного рекурсивного снимка и рекурсивной отправки / записи, независимо от цели (это может быть другой диск в качестве расширенной файловой системы). другая система ZFS, облачное хранилище с поддержкой ZFS или даже tarball в любой другой системе).
Этот поворот отличается от обычных снимков и должен называться по-разному, например, с префиксом в сочетании с датой или увеличением числа, например data@offsitebackup_217 . Имена не имеют значения для внутреннего использования, но если вы пишете сценарий, вам нужно быстро найти последнюю существующую резервную копию (или запомнить имя где-то еще), так как вам нужна дельта между последней переданной и вновь созданным снимком:
# full initial send, destroy all filesystems on the destination
# which are not present on the source
zfs snapshot -r data@offsite_backup_1
zfs send -R data@offsite_backup_1 | ssh user@host zfs recv -Fdu data
# incremental send, destroy all filesystems on the destination
# which are not present on the source
zfs snapshot -r data@offsite_backup_2
zfs send -R -I data@offsite_backup_1 data@offsite_backup_2 | ssh user@host zfs recv -Fdu data
zfs destroy data@offsite_backup_1
Что касается корневого пула, он только немного отличается: если вам нужно заменить диск, вы должны сначала создать загрузочный / подкачку и записать загрузчик как обычно, затем вы восстановите снимки и, возможно, также точки монтирования. Я думаю, что beadm на Solaris делает то же самое. Конечно, локально вы пропускаете часть ssh user@host . Опять же, первое тестирование с небольшим количеством данных (реальные тесты необходимы, флаг -n здесь не будет работать).
Копировать данные
Теперь вы можете копировать или перемещать все свои данные (обычным способом, например, cp или rsync).
