dd if=dev/sda1 | zstd - | dd of=/path_to_backups/fs.img.zst - так можно?

dd if=dev/sda1

Отрицательно полезная конструкция. Предлагаю pv /dev/sda1 если нужен прогресс, </dev/sda1 если не нужен.

dd of=/path_to_backups

>/path/to/backup

Насколько разумный способ?

В сравнении с чем?

И можно ли модернизировать вот таким образом

Можно.

Предлагаю pv /dev/sda1

Спасибо! Интересная утилита!

Вопрос: всё так?

pv /dev/sda1 | zstd - | >/path/to/backup/fs.img.zst

pv /path/to/backup/fs.img.zst | unzstd - | >/dev/sda1

Без лишнего |. Он для передачи между процессами, а с > мы обходимся без лишнего процесса, который все равно ничего с данными не делал.

pv /dev/sda1 | zstd - >/path/to/backup/fs.img.zst

pv /path/to/backup/fs.img.zst | unzstd - >/dev/sda1

Понял! Это точно нужно в заметки. Огромное спасибо!

pv не везде есть, в отличие от dd и gzip

dd if=/dev/sda1 status=progress | zstd -c  > /path_to_backups/fs.img.zst

Ну и в обратку, наверно:

unzstd -c /path_to_backups/fs.img.zst | dd of=/dev/sda1 status=progress

https://wiki.archlinux.org/title/Dd#Create_disk_image

в dd проресс есть через sigUSR2

Давно уже запилили «status=progress».

Куруто. Теперь-то заживём!

Я в курсе, потому и предложил замену в виде pv.

Теперь-то заживём!

Учитывая, что этому параметру скоро 10 лет, добро пожаловать из криокамеры. )

Ладно, несмешная шутка.

Ддшкой снимать образы неэкономично по размеру

Если свободное место перед этим занулить, то норм. Да и что ещё делать, когда нужен сырой образ?

Сделай образ, разверни втуда бэкап. Делов-то

Сделай образ на каком уровне? Бэкап какого уровня?

Архив с фс

Допустим у тебя в руках загрузочная флешка из бытового ежевыжимателя. Надо сделать бэкап её всей. Что именно ты предлагаешь делать во имя экономии? Есть какое-то удобное общее решение?

Отлично! Забил нулями и, как оказалось, действительно - жмется на порядок лучше.

pv /dev/zero > /path/to/the_file_to_be_deleted

Что именно ты предлагаешь

Вот пример сообщения, где автор думает, что есть только один кейс в мире. Поздравляю, вы *********!

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

Что это значит?

Создать файл, состоящий из нулей и занимающий всё свободное место на разделе. Потом удалить. И после этого размер архива уменьшается в разы.

Конкретно в моем случае - примерно в 20 раз уменьшился размер архива. Плюс время развертывания также снизилось.

Но, к слову, сейчас встретил такое утверждение:

dd if=/dev/zero of=/dev/sdX bs=1M

dd copies bits from «if» to «of». Blocksize 1M is usually a good value for performance. Repace sdX with your actual drive.

If you need to track progress, install «pv» (pipeviewer)

pv /dev/zero > /dev/sdX

or, in newer versions of dd, specify status=progress (which will actually be faster as there is a slight overhead using pv).

В переводе примерно так:

в более новых версиях dd, укажите status=progress (что на самом деле будет быстрее, поскольку при использовании pv возникают небольшие накладные расходы)

Взято из обсуждения, истина или ложь - не проверял.

Прочти на досуге

Снова о бекапировании с помощью dd

Да, исчерпывающе. Спасибо за тему!

А ты — пример прихода в тред по снятию образа ФС и предложения этого не делать.

А для утилиты pv эти вещи тоже актуальны?

Снова о бекапировании с помощью dd (комментарий)

Снова о бекапировании с помощью dd (комментарий)

conv=sync,noerror

Не думаю, что в pv такое есть. Ребята, кажется, изобретают ddrescue, а чем его изобретать, лучше его использовать.

bs=64M

-B 64M

ddrescue

Удивительная вещь Linux, всё уже придумано до нас.

-B 64M

Спасибо, поправил!

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

А в случае SSD, может просто сделать TRIM вручную для раздела? Это не равно заполнить нулями свободное место? Насколько я знаю после вызова discard сектора все данные из него теряются в отличии от от HDD и в случае именно моего SSD пустое место заполнено нулями, а вот насчет других моделей не знаю. Бэкап тоько что установленной системы у меня не очень хорошо сжался, напротив тот на котором я сделал TRIM вручную весит раза в полтора меньше.

Может, я не настаивал на конкретном способе их зануления.

Это от прошивки ssd зависит. Для ATA это свойство выдаёт ″hdparm -I″.

Там может быть ″Deterministic Zeroes After Trim", тогда будут нули, после trim. А у других SSD может быть «Deterministic Read After Trim», тогда не нули, а преждние данные. А может быть вобще «Non-deterministic Trim».

Как это узнать для M.2 pci-e не знаю.

А у других SSD может быть «Deterministic Read After Trim», тогда не нули, а преждние данные.

Разве после команды Trim контроллер SSD не должен готовить ячейки для возможности записи новых данных, т.е. очищать их? (что там при этом будет, нули или единички, конечно, неважно) Ну некоторое время, пока он этого ещё не сделал, там могут быть старые данные, но не очень долго. Иначе в чём смысл Trim?

Для интереса посмотрел (Samsung SSD 850 EVO 250GB)

# hdparm -I /dev/sda | grep -i trim
	   *	Data Set Management TRIM supported (limit 8 blocks)

там могут быть старые данные, но не очень долго.

Только это «не очень долго» может измеряться не секундами, а количеством операций записи. Алогоритм может просто поддерживать зданное число блоков, готовых к записи, и пока их хватает не подготавливать к записи новые (тримнутые) блоки.

Даже котроллер, у которого ″Deterministic Zeroes After Trim", не обязательно стирает сектор сразу после TRIM, он просто при операции чтения проверяет и возвращает нули, если сектор «освобожден». С флеш стираются только большие блоки, если освобождён только один сектор в блоке, то чтобы его стереть нужно все остальные сектора перезаписать. Это плохо с точки зрения износа флеша.

Даже котроллер, у которого ″Deterministic Zeroes After Trim", не обязательно стирает сектор сразу после TRIM, он просто при операции чтения проверяет и возвращает нули, если сектор «освобожден».

Я тоже пришел к такому выводу, когда по собственной глупости пере разметил не тот диск. И потом долго пытался восстановить хоть что нибудь с него разными программами. Но ни одна программа ни с какого Live CD в упор ничего не находила, тогда я полез смотреть содержимое секторов и обнаружил, что там одни нули. Тогда я недоумевал, как так быстро можно все нулями записать, да и главное зачем. Потом подумав я прошел к выводу что виноват во всем TRIM ибо перед удалением раздела нужно сообщить контроллеру что данные сектора свободны, а он в свою очередь выдает что там нули при последующем обращении. В случае HDD у меня бы получилось и я бы все восстановил, но я узнал всю мощь SSD. Надеюсь эта информация будет кому нибудь полезна.

Погуглил

«Deterministic Read After Trim (DRAT): the SSD controller will always return a pre-defined value when reading trimmed blocks regardless of their actual content. The value could be all zeroes, but it could also be something else (SATA Word 69 bit 14).»

Т.е. не факт, что контроллер выдаст то, что было записано в секторах ранее, до трима. Просто, насколько я понимаю, вне зависимости от того, очищены ячейки (с флагом трим) или ещё нет, контроллер выдаст то, что ему предписано.

https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/

Да, не факт что выдаст ранее записаное. А если ещё добавить, что каждый прозводитель имеет своё представление о стандартах, а в прошивках могут быть ошибки, то что будет при чтении после TRIM вобще прогнозировать сложно.

По вашей ссылке странные формулировки, в стандарте так:

a Non-deterministic read after trim behavior: each read command to the logical block may return different data.

b Deterministic read after trim behavior: after a read command has completed processing, the data in that logical block becomes determinate (i.e., all read commands to the logical block shall return the same data).

То есть конроллер в случае deterministic должен всегда возвращать одинаковое содержимое сектора, у него есть время «подумать» до первого чтения. Он может вернуть старое (до TRIM) содержимое сектора, но тогда обязан всё время возвращать его же, пока не сектор не будет записан. Хотя производитель может видеть иначе.

Мне не один ssd встречался, возвращающие старые данные после trim.

Но в этой теме подобное уже нюансы. Эта ветка начилась с того, что в общем случае TRIM — это не равно заполнить нулями пустое место, что необходимо для лучше компрессии образа ФС.

Можно делать trim и проверять флаг ″Deterministic Zeroes After Trim", но на совести производителя. Можно попробовать проверить, что после trim сектора «обнулились», но сложно. А можно создавать файл с нулями на всё свободное место, но лишняя запись.

Подскажите, а при восстановлении раздела размер блока ведь указывать не нужно? И правильно ли я записал первую строку?

pv /dev/sda1 -B 64M | zstd - >/path/to/backup/fs.img.zst

pv /path/to/backup/fs.img.zst | unzstd - >/dev/sda1

Размер блока = тюнинг производительности, и вряд ли ты много на этом выиграешь. Можешь указать, тогда в конце вместо >/dev/sda1 надо ставить | dd of=/dev/sda1 bs=СКОЛЬКОНАДО. Ошибок не вижу.

Меня особенно первая строка волновала. Спасибо, что проверили!