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

Без noerror при наличии ошибки чтения dd прекратит работу. Если устраивает такое, можешь прибить. sync добивает блок нулями, на случай, если объем диска не кратен bs. Ну или в случае битого сектора.

Без noerror при наличии ошибки чтения dd прекратит работу. Если устраивает такое, можешь прибить.

Конечно устраивает, и об этом уже писал. Пусть себе прекращает, и тогда я узнаю, что есть проблемы с диском.

Значит noerror можно исключить?
А sync нужно оставить, что ли? в виде conv=sync ?

Но зачем? Зачем добивать блок нулями? Пусть будет в «хвосте» блока что угодно - нули, единицы, пятерки - разве это так важно?

нет смысла объем в bs=64k сжимать несколькими потоками..

conv=sync,noerror

Это такой способ получить кривой дамп.

Dd читает исходные данные блоками фиксированного размера. В твоём случае ты запрашиваешь размер в 64 * 1024 байт. Читает он вызовом read(), который может вернуть как 64 * 1024 байт, так и меньше. Если он возвращает меньше, то dd просто считает, что read() вернул 64 * 1024 байт. Перед чтением dd зануляет внутренний буфер, поэтому всё выглядит как дополнение прочитанных данных NULями до 64 * 1024 байт.

Есть несколько причин, по которым read() может вернуть меньше данных, чем запрашивалось. Я знаю две: «файл кончился» и «ядро решило прервать вызов». Если окончание файла ещё можно предсказать, то вот что там у ядра случится предсказать вряд ли выйдет. Если подобное произойдёт, то в выходной файл из-за conv=sync уйдёт полный блок, а вот во входном файле смещение будет меньше блока. В итоге у тебя весь образ съедет на сколько-то байт.

А, и ещё conv=sync округлит размер выходного файла вверх до ближайшего множителя размера блока. Из входного файла в 6 байт будет сделан файл в 65536 байт. То есть с conv=sync ты ещё и информацию о размере файла частично теряешь. Это уже гарантированно, каждый раз.

В вашем примере sync имеет смысл только вместе с noerror. Чтобы при ошибке чтения сектора записываемый блок был добит нулями и тогда последующие блоки запишутся без смещения. Но при этом нужно бы делать размер блока равный размеру физического сектора носителя.

Сжимать образ диска это хорошо, только сложно понять потом какого он размера в несжатом виде, да и подмонтировать ФС из такого образа сложно. Так что может их лучше расжимать из gzip и зажимать в mksquashfs...

и тогда последующие блоки запишутся без смещения

Зато читаться блоки будут со смещением. Использовать conv=sync или conv=sync,noerror это очень плохая идея.

я бы использовал partclone.

Тут https://superuser.com/questions/622541/what-does-dd-conv-sync-noerror-do приведён пример, что при bs=512, выходные файлы команд dd и ddrescue совпадают. Правда, там «сбойный» диск эмулировали через dmsetup. Так что в горящем танке при отсутствии ddrescue и бекапов, я буду пытаться дампить посыпавшийся винт командой:

dd bs=512 conv=noerror,sync if=/dev/...

Если кому-то нужно, то вот пример создания squashfs из выхлопа dd через ssh без записи промежуточного файла: https://semjonov.de/posts/2021-05/create-squashfs-archive-from-stdin-and-sign...

не проверял.

приведён пример, что при bs=512, выходные файлы команд dd и ddrescue совпадают

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

Но практически везде советуют использовать dd именно с conv=sync,noerror.

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

Парни, спасибо, пока я очень внимательно изучаю ваши мнения, потом отпишусь.

Но вот насчет этого -

я бы использовал partclone

отвечу сразу: фтопку!!!

Потому что:

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

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

Когда-то в древние долинуксовые времена я так погорел на такой «интеллектуальной» утилите, емнип, называлась Ghost.
Наклепал ею кучу бекапов дисков с вынь98, и однажды, когда потребовалось их восстановить, получилась полная ж.опа - ФС получилась настолько битая, что вында хромала на все 3 ноги.

Потом нашел нормальную dumb утилиту, без «нейронных сетей» - Partition Magic, и вот ею потом делал много бекапов и восстановлений, и сбоев ни разу не было.

Тогда я получил хороший урок, и теперь убежден:

- утилита для бекапирования разделов должна быть простой как винтовка Мосина и иметь единственное право:

ТОЛЬКО ТУПОЕ КОПИРОВАНИЕ БЛОКОВ!

И никакой другой самодеятельности!
Кому надо получать меньшие размеры, то только за счет самостоятельных (а не встроенных) архиваторов.


PS. Пока еще пользуюсь Clonezilla, но она чем-то мне не нравится, чем именно, сам не пойму.
Вариант с dd мне нравится гораздо больше.

Тогда я получил хороший урок, и теперь убежден:

• утилита для бекапирования разделов должна быть простой как винтовка Мосина и иметь единственное право:

ТОЛЬКО ТУПОЕ КОПИРОВАНИЕ БЛОКОВ!

С отмонтированной файловой системы.

С отмонтированной файловой системы.

Это само собой :=)

Освоил пока только бекапирование, т.е. «туда».

Отлично, теперь восстанови из этого бэкапа случайно удаленный каталог /home/chukcha/documents/work/important.

man mount

Последовательность действий давай. Есть пожатый 250Гб->50Гб дамп. Дальше?

дальше писю сосать распаковывать образ и монтировать в луп и выковыривать из него файлик в 5 кб :) пройденный этап.

PS. Пока еще пользуюсь Clonezilla, но она чем-то мне не нравится, чем именно, сам не пойму.

Так там же тот же dd под капотом выбрать можно. :)

Это замечательно, но смущает связка conv=sync,noerror - на кой ляд она здесь надо?

Это прекрасно, утро сделано. Тебя никто за язык не тянул? Злые духи на ушко не шептали: «конв… равно… синк… запятая…»? Значит на кой ляд ты это написал, на тот и надо.

Вот я именно об этом. УДОБНО.

Очевидно, что резервное копирование имеет разные задачи. Если стоит задача без особых усилий сделать копию всей системы с последующим лёгким разворачиванием, то возможно извлечение отдельных файлов заставит страдать. Если стоит задача без особых усилий сделать копию файлов то возможно восстановление загружаемой и работоспособной системы заставит страдать. Если есть задача сделать и то и другое то возможно организация процесса заставит страдать.

Ты хочешь у меня спросить какую задачу ставят в данном случае? Или какое именно страдание выбирают?

Неловкий вопрос — а зачем вам fs-level backup, если ваш юзкейс — доставать файлики в 5кб? Zip? Vcs? Снепшоты? Просто копия каталога, наконец (возможно, с xz на каждый файл по отдельности)?

и заодно сжимает на лету эти разделы примерно в 5 раз (!)

Чую, кто-то в треде не шифрует диски.

И тебе неловкий вопрос — а какого экзотического фрукта надо шифровать диски? Ты стесняешься своего /bin/bash? Plasma Vault для кого придумали?

а какого экзотического фрукта надо шифровать диски?

Вот от тебя не ожидал «мненечегоскрывать»-риторики. Живи скучной жизнью, не работай нигде, можешь хоть ноуты терять — твоё право.

Ты стесняешься своего /bin/bash?

У меня нет /bin/bash, но систему может воспроизвести любой анон в одну команду, тут все публично: https://github.com/t184256/nix-configs

Plasma Vault для кого придумали?

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

Ты хочешь у меня спросить какую задачу ставят в данном случае?

Я хочу, чтобы ты признал свой «man mount» глупым комментарием.

А может у него просто 80% места свободно.

дык я и перешел на squashfs файлов раздела, xz кстати в нем тоже есть.
если говорить про восстановление корневого раздела на чистый носитель, то после разворачивания системы надо будет восстановить бут-сектор груба - небольшая элементарная операция.
при этом тут тебе и удобство монтирования образа с произвольным доступом, год назад реально одну железку переводил с 32бит на 64бита, накатил новенькую чистенькую систему, образ старой системы смонтировал в /mnt и не торопясь восстановил настройки на новой системе. удобно, просто и очень наглядно.
ну и отсутствие захватывания ошметков стертых блоков в бекап и т.д.
минус один - пара дополнительных действий для рут-раздела.

«мненечегоскрывать»

Что? Шифровать стоит только чувствительные данные. Шифровать всё — маразм и дебилизм.

Раньше то же backup только dd делал. Теперь только Acronis.

Что?

Ну давай в твоем формате отвечу. Шифровать стоит просто всё, благо AES-NI уже 8 лет на рынке. Тратить время на избирательное шифрование — вот это маразм и дебилизм.

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

Во, как! Думал времена этой конторы давно ушли…

Парни, не сорьтесь, у вас очень интересная и полезная дискуссия :=)

маразм и дебилизм основа некоторых военных систем.

А какую задачу ты предлагал мне решать глупым комментарием с «man mount», м?

кстати, gzip увы, однопоточный

pigz уже давно существует.

Остальное уже написали.

Дамп блочного устройства - путь не очень, слишком большой оверхед

Значит на кой ляд ты это написал

Чукча не читатель, чукча - писатель.

Бесполезная совершенно. Попробуй любой сценарий восстановления, ужаснись и забудь про dd. И другим передай.

Чукча не комментатор, чукча - топикстартер.

pigz уже давно существует.

Бесполезен - не научился каталоги сжимать.
Потому и упомянул 7zip.

ты жмешь выхлоп dd, он представлен в виде одного единственного потока, какие нахренъ каталоги, ты сейчас о чём ??

А так, на всякий случай. Если он каталоги не жмет (хотя при бекапе разделов он действительно не нужен), то зачем вообще с таким кастратом иметь с ним дело? 7zip же!

Ты б еще спросил, зачем на стороне приёмника dd с bs=64k.

Изучи разницу бежду компрессором и архиватором )

Не вижу ничего плохого в «интеллектуальных» юзер-френдли утилитах.

1. Периодическая авто-проверка целостности бэкапа - эта одна из стандартных фич таких утилит. Конечно, и здесь может проскользнуть баг, поэтому…

2. Нужно делать резервное копирование как минимум двумя разными программами (в два разных места). Ошибкам подвержен любой софт, самописные скрипты вокруг coreutils не исключение. Но вероятность просёра бэкапов снижается экспоненциально с увеличением числа бэкапирующих программ. Тут также уместно припомнить «правило 3-2-1»

у меня два варианта делчев и крупский «штоп памяти меньше жрало и скорость была» и «так было написано»

У меня один)

делчев ??