riv
на старой машине создадим новый актуальный снимок с именем snap-for-send-01
zfs snap rpool/cloud-storage@snap-for-send-01
затем посмотрим сколько данных будет передаваться, вам же хочется видеть прогресс?
zfs send rpool/cloud-storage@snap-for-send-01 -nv
или, если вы хотите получить машиночитаемый результат:
zfs send rpool/cloud-storage@snap-for-send-01 -nP
Далее запускаем передачу на новый пул, предположим, что он тоже называется rpool и на нем ОТСУТСВУЕТ датасет rpool/cloud-storage
пример 1, просто передача без сжатия и визуализации процесса
zfs send rpool/cloud-storage@snap-for-send-01 | ssh root@192.168.0.11 "zfs receive rpool/cloud-storage"
но лучше сделать визуализацию, чтобы отслеживать прогресс, предположим, что на предыдущих шагах, объем передачи данных 112Гигобайт, вы увидите красивый прогрессбар. Имейте в виду, что если вход ssh по ключам не настроен, вывод утилиты pv закроет приглашение ввода пароля, но его все равно надо ввести всдепую
zfs send rpool/cloud-storage@snap-for-send-01 | pv --size 112G | ssh root@192.168.0.11 "zfs receive rpool/cloud-storage"
ещё лучше сжать данные при передачи, поставьте пакет liblz4-tool или другой быстрый архиватор, который может работать в режиме pipe
zfs send rpool/cloud-storage@snap-for-send-01 | pv --size 112G | lz4c -c | ssh root@192.168.0.11 "lz4c -d | zfs receive rpool/cloud-storage"
Николай
Спасибо большое, буду пробовать
Δαρθ
а в чем профит send/recv по ср с пофайловым копированием через тот же rsync?
Fedor
я бы просто порекомендовал сервис перенести и воссоздать на новом месте, после чего влить данные.
Fedor
а если это будет производиться через бекапы - тем лучше.
Fedor
а тут - встроенное
riv
у ssh есть ключ -C который включает сжатие.
лучше его выключить и спользовать подходящее сжание для каждого случая своё:
# В локальной сети - работает очень быстро
lz4c -z | lz4c -d
# через медленныйканал (хорошо сжимает)
bzip2 -c -3 | bzip2 -d -c
# на очень мощном сервере со стороны отправки (amd epyc) (очень хорошо сжимает, но на гигабитном канале может нагрузить 20-30 ядер на 100%)
pbzip2 -c -9 | pbzip2 -d -c
Fedor
это уже оптимизации :)
Ilya
а в чем профит send/recv по ср с пофайловым копированием через тот же rsync?
Send recv копирует только изменённые блоки, не перечитывая файлы целиком
Ilya
https://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/
riv
Send recv копирует только изменённые блоки, не перечитывая файлы целиком
Кроме того, бывают такие ошибки в файловой системе, например имя больше 255 символом после переименования, которые могут вызвать сбой cp, tar и других утилит. send работает на блочном уровне и создаёт наименьшую нагрузку на дисковую систему.
Кроме того, zfs receive поддерживает ключ сохранения не до конца переданного потока и передчу можно возобновить с того места где она прервалась. Еще можно отправлять разинцу между снимками и т.д.
Это целая технология.
Николай
Парни нашёл решение проще, я беру диски физически их переношу на новый сервак там импортирую этот пул после , добавляю в рейд нужный мне диски файлы автоматом туда перекачуют и после я выйму старые. Сработает?
Fedor
только экспортируй сначала (вроде бы)
Fedor
но про автоматом это вопрос.
Ilya
Файлы не уйдут со старых дисков.
send|recv - наиболее адекватный метод, раз с обеих сторон zfs
Δαρθ
Send recv копирует только изменённые блоки, не перечитывая файлы целиком
это если дифф между 2 шотами слать?
Ilya
первое копирование - в любом случае "полное", а дальше последующие снапшоты и будут как раз слать дельту между предыдущим состоянием и нынешним
Δαρθ
ну да
но у вопрошающего как раз 1ый случай
riv
ну да
но у вопрошающего как раз 1ый случай
send receive самый правильный способ. Остальное несёт доп риски.
Δαρθ
какие например риски? я не очень админ ынтерпрайза, с такой точки зрения на вещи не смотрю
Δαρθ
я согласен что правильный для посылки диффов между шотами, да
riv
какие например риски? я не очень админ ынтерпрайза, с такой точки зрения на вещи не смотрю
Например можно накосячить при манипуляции с дисками. Это опаснее чем штатные механизмы send | receive
Δαρθ
riv
а потом вам же только один датасет ндо перенести, а с дисками вы весь пул, как я понимаю скопируете. Ошибетесь в пути к диску, перепутаете буквы, цифры и т.д.. В общем человеческий фактор.
nAHKPATOB
Общий привет.
Есть проблема с потерей места на zfs, никак не могу разрешить эту проблему, может тут кто поможет?
central
central
zfs get all <pool>
Владимир
nAHKPATOB
Хотел переслать из другого чата, а тут нельзя, сейчас будет
nAHKPATOB
Владимир
тебе выше команду дали
Ivan
nAHKPATOB
Владимир
compressratio 31.03x
Владимир
херасебе
central
du и df выдают разные результаты
Также и zfs list противоречит du
все это вполне известные моменты в которых нету ничего необычного
nAHKPATOB
nAHKPATOB
nAHKPATOB
nAHKPATOB
Δαρθ
Δαρθ
видимо 9 терабайт нулей, которые упаковались в 300 гигов
Δαρθ
dataset aid/ROOT/default -- в нём
nAHKPATOB
видимо 9 терабайт нулей, которые упаковались в 300 гигов
Там интересная штука что объект 98(это как раз файл на 10тб) стоит в очереди на удалении, а как запустить эту очередь я не знаю, и почему она стоит, тоже не ясно
Ivan
Там интересная штука что объект 98(это как раз файл на 10тб) стоит в очереди на удалении, а как запустить эту очередь я не знаю, и почему она стоит, тоже не ясно
lsof надо глянуть, возможно файл кто-то держит
Dim
nAHKPATOB
lsof надо глянуть, возможно файл кто-то держит
Так если у него нет имени как же его найти?
И родителей у него 97 и 96 нет
Ivan
Так если у него нет имени как же его найти?
И родителей у него 97 и 96 нет
а какое имя было при удалении ?
nAHKPATOB
а какое имя было при удалении ?
А кто его знает, это было почти год назад, может при обновлении системы, или кусок от мускул, а может и из тмп мусор, неизвестно, но, с большой долей вероятности можно сказать, что это скорее всего не снимок, т.к согласно хистори в этот день(и даже соседние дни) не создавались никакие снимки, а вот отключение эл.энергии вполне могло быть.
А так то я постопоянно делаю бакапы посредством снимков zfs send через xz в фаил.
В разных местах пишут, что есть такая болезнь у zfs, что при удалении снимков(или файлов) свободного места становится МЕНЬШЕ!
Но у меня с десяток серверов на FreeBSD ZFS и это единственный случай.
Alexander
Добрый вечер,
1) Подскажите, может ли какой-нибудь зловред перезаписывать содержимое снэпшотов незаметно?
Не в смысле клонирования, монтирования и записи как обычно незловреды, а именно изподтишка?
2) Встречались ли вам хотя бы упоминания буткитов шифровальщиков, которые незаметно шифруют устройства пула vdevs?
Mikhail
Я не настоящий сварщик ибо вопросы понял частично. На bsd использую geli+zfs.
Alexander
Ну так многие используют осознанное полнодисковое шифрование (например LUKS) + ZFS.
Проблема в существовании невидимых программ в защищенных рингах (приоритетнее ядра).
Что им мешает зашифровать диск еще ДО LUKS своими алго, а потом в час Х потребовать с вас баблища?
Ivan
Ну так многие используют осознанное полнодисковое шифрование (например LUKS) + ZFS.
Проблема в существовании невидимых программ в защищенных рингах (приоритетнее ядра).
Что им мешает зашифровать диск еще ДО LUKS своими алго, а потом в час Х потребовать с вас баблища?
да и ты сам можешь находиться в симуляции
Alexander
да и ты сам можешь находиться в симуляции
Мне от этого не легче, если у меня в текущей инкарнации залочат диски.
Это еще без учета родной прошивки дисков, которая по сигналу на шине может тупо отрубить их работоспособность.
Алексей
Alexander
а что им мешает после лукс?
Действительно без разницы до или после, если они в ядре достаточно хорошо ориентируются.
А хотя разве это можно без дополнительного видимого устройства DM?
Alexander
Хотя впихнуться между пулом и LUKS сложнее IMHO, чем поверх true raw железки.
Алексей
не нужно никуда впихувотса достаточно рута
Alexander
Вы про права пользователя? А как это с точки зрения ядра будет выглядеть?
Алексей
как действие пользователя как же ещё
Alexander
Какое еще действие? Я не про шифрование файлов поверх FS, а как вложить свой слой шифрования между DM cryptsetup и vdev ZFS в терминологии сервисов ядра?
Mikhail
Ну я слышал про то что шифровалка в самих контроллерах ssd бывает похацкана. Но только один раз такое было и не верится как то.
Mikhail
И это в отрыве от zfs конечно
Alexander
Да щас такие навороченные контроллеры даже в обычных HDD для файлопомоек. На Хабре вон пролетают статьи, как расхерачить и кастомизировать прошивку диска, пипец вообще.
Mikhail
расчехарить не сложно, а вот пропатчить, подписать и ещё протолкнуть в какой то датацентр - это какой то прям супер геройский подвиг
Alexander
расчехарить не сложно, а вот пропатчить, подписать и ещё протолкнуть в какой то датацентр - это какой то прям супер геройский подвиг
Да мне пофик на датацентры, меня домашние диски больше беспокоят :)
У них там бабла, они этих хацкеров с того света достанут или заново отстроят свои датацентры.
Mikhail
Бекапы?
Alexander
Или на зараженные буткитами приводы лент?
Или на зараженные буткитами приводы болванок Blueray?
Ilya
На заражённые буткитами бумажные блокноты
Alexander
Перфокарты рулят, епт.
С электромеханическими приводами.
Кстати у флоповодов ведь не было прошивок?
Половина участников чата поди и не знает, что такое флоп :)
А у меня вон целых 3 новеньких нераспечатанных упаковки. Можно ZFS пул поднимать.