Задать вопрос

rPman

Ответы пользователя по тегу ZFS

  • Truenas, пул zfs, возможно ли будет вытащить данные если диск подключить к другому компьютеру?

    @rPman
    Нет, сами пулы не имеют никаких настроек прав доступа (собственно поэтому шифрование и используют, что бы защититься от этого), на новом компьютере можно будет получить к ним доступ
    Ответ написан
    Комментировать
    Комментировать

  • Вопрос по надежности ZFS. Как лучше делать датасеты: со сжатием или без?

    @rPman
    чем сложнее файловая система, тем менее вероятно восстановление после сбоя.

    zfs, точнее любая cow файловая система, искусственно фрагментирует размещение файлов на диске (при их изменении), т.е. каждый раз когда вы пишете в файл, этот кусок записывается в новое место... представляете какая каша получается из данных на диске, если это восстанавливать?

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

    p.s. настоятельно не рекомендую рассчитывать на восстановление данных на основе 'что то смогу восстановить', лучше используйте raid1/5/6 (6 версию рекомендую, от 4 дисков, суммарный объем меньше на 2 диска), в этом случае вы значительно будете защищены от аппаратных сбоев на диске (но не в контроллере и не в софте).

    От софтовых проблем защищайтесь регулярными снапшотами, их же используйте для онлайн инкрементального резервного копирования (btrfs и zfs умеют быстро считать разницу между указанными снапшотами, формировать их в файл, который можно обратно развернуть на другой файловой системе, если делать это последовательно, начиная с первого снимка)
    Ответ написан
    Комментировать
    Комментировать

  • Можно ли ускорить запись на ZFS через кэш?

    @rPman
    Zfs не умеет кешировать записи.

    Есть блочная прослойка bcache, позволяющая из двух и более дисков сделать один раздел, указав стратегию кэширования для присоединенных дисков (один диск главный, остальные кеш), там кеширование записи присутствует. На полученном разделе можно использовать любую файловую систему.

    Настоятельно не рекомендую так делать, тем более из-за торрентом, вы убьете лимит записи ssd за год или меньше... Посмотрите статистику скачивания и раздач у вас, так вот на ssd может прийти во много раз больше записей чем ожидается, ведь кешировать будут и чтения.

    Торренты лучше кешировать средствами клиента, например это умеет tixati, опция move on complete
    Ответ написан
    1 комментарий
    1 комментарий

  • Можно ли гарантировать надежность снапшота?

    @rPman
    Создание снапшота - атомарная операция (lvm/btrfs/zfs), с точки зрения восстановления базы данных из этого снапшота, это будет то же самое, как если бы вы нажали reset на компьютере, даже лучше - сняли все процессы сервера баз данных с помощью жесткого kill -9 $pid (SIGKILL, его не отловить) ведь записи на диск не прервутся.
    ВАЖНО, если база данных находится на одном томе! невозможно создать атомарно снапшот на нескольких томах. Вариант с запуском всей системы в виртуальной машине и созданием снапшотов ее средствами не рассматриваем, такой конфиг абсурден с точки зрения производительности.

    Базы данных очень качественно следят за консистентностью записи, удаляют данные из лога только после того как завершат запись на диск, т.е. транзакция не завершится, пока данные не будут записаны окончательно. Это значит данные не будут повреждены.

    С некоторой вероятностью, базу данных придется поднимать вручную, т.е. потребуется проверка целостности, например логи будут повреждены и их нужно будет удалять и т.п. Но обычно postgres справляется с аварийным выключением неплохо.

    p.s. но я бы не рекомендовал такой способ все равно, особенно на постоянной основе.
    Для создания резервной копии на живой базе я рекомендую использовать вторую машину, на которую настроена репликация базы. В этом случае эту вторую базу можно остановить, снять снапшот, возобновить работу (чтобы репликация догнала master - меньше нагрузка на диски, меньше оперативной памяти и допустим слабый процессор) а снапшот спокойно копировать, не опасаясь каких-либо проблем.
    Данный способ нужно использовать на постоянной основе (мало того, требования к backup slave серверу значительно ниже чем рабочему master), и сам процесс создания копии никак не повлияет на работу исходной базы, когда как использование оригинальной базы, даже со снапшотом, значительно понизит ее производительность, так как копирование сильно нагружает дисковую подсистему.
    Ответ написан
    3 комментария
    3 комментария

  • ZFS + аппаратный RAID?

    @rPman
    У тебя варианты
    за кеширование пусть отвечает:
    - ZFS, будет доступно только режим на чтение
    - bcache - создается блочное устройство, которое в свою очередь уже форматируешь под желаемую фс, будет доступен режим кеширования записи (опасно, при смерти ssd потеряешь данные, я экспериментировал, убил два ssdшника за пару лет в таком режиме, в момент смерти файловая система повреждается, ос подвисает, так как часто ssd-шники в режиме чтения после этого еще работают, данные в основном вытаскиваются, но время на восстановление я тогда потратил), настоятельно рекомендую при использовании кеширования записи bcache, ssd брать два в режиме raid1 mirror

    за RAID:
    - отдать на откуп управление raid на ZFS, получишь максимальную гибкость (операции ребалансировки не будут затрагивать незанятое данными место)
    - отдать RAID на откуп mdadm
    - (не вариант, не делай так) организовать RAID на основе аппаратного контроллера в материнской платы, кешированием так же занимается ZFS
    если raid контроллер не имеет своей оперативной памяти с аккумулятором для сброса этой памяти на диск в момент потери энергии, то выбирать такой рейд контроллер нет никакого смысла, а вот проблем будет тьма, особенно в текущей ситуации с проблемами с поставками, так как аппаратные рейды привязывают массив к вендору, и при смерти контроллера/материнки у тебя будет проблема с извлечением данных (это реально но долго и сложно)

    p.s. можно выбрать btrfs, по функционалу, чуть хуже (нет онлайн дедупликации, но много ли ее включают дома на zfs, ведь это потребует прилично оперативной памяти), нет встроенного ssd кеша но есть онлайн патчи между снапшотами за счет которых можно построить неплохую систему инкрементальных бакапов с максимальной производительностью (можно делать бакапы хоть ежеминутные, лучше объединить с рабочим софтом, чтобы он управлял моментом создания снимка) с отправкой инкрементальных патчей на стороний сервер (где их тут же можно и развернуть для мгновенного переключения на этот сервер при смерти основного)
    Ответ написан
    Комментировать
    Комментировать