Какие ежедневные команды мне нужно использовать для выполнения вышесказанного? (Практически любое руководство в Интернете связано с 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 или даже тарбол в любой другой системе).
Этот поворот отличается от ваших обычных снимков и должен называться четко, например, с префиксом в сочетании с датой или увеличением числа, например 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на Солярисе делает по существу то же самое Конечно, локально вы пропускаете ssh user@hostчасть. Опять же, первое тестирование с небольшим количеством данных (реальные тесты необходимы, -nфлаг здесь не будет работать).
Копировать данные
Теперь вы можете копировать или перемещать все свои данные (обычным способом, например cpили rsync).