Неудачный опыт преобразования btrfs в ext4

Теста ради делаю той же командой новый бекап папки boot и все работает, архив открывается

Чем больше объём тем больше вероятность, что tar сбойнёт. boot маленький, поэтому проскакивает успешно

Несколько раз нарывался на то, что tar тупо пропускает часть файлов. Их просто нет в результирующем архиве. Т.е. делаешь два архива одной и той же файловой системы - размеры архивов разные, причем разница огромная, 5Гб и 3.7Гб.

Стал юзать rsync

bsdtar --acls --xattrs -cpaf

https://wiki.archlinux.org/title/Full_system_backup_with_tar

Снова попробовал

tar -czpf /media/ubuntu/e435242657/ /media/ubuntu/backup_partition/ubuntu.tar

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

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

нормально в тар упаковывался бекап корня. пока на squashfs не перешел. но это к теме бекапов.

у тебя опять же ошибка
tar -f файл_архива /место/откуда/собирается/архив/
опция -f требуется сразу за ней прописывать имя файл

rsync не умеет архив :) rsync работает с файловой структурой.

кстати идея, да, создать новый раздел ext4.. думаю это подходит, с bsdtar у меня тоже ошибки.. видимо ключи не те или что то надо переставить ключи..

думю даже так - создам временный раздел екст4, туда, потом переформатирую бтрфс в екст4 и залью файлы орбратно и изменю UUID

зачем ?? местоположение корневого раздела ни на что не влияет… даже на hdd несильно скорости будут отличаться.

интересно, а ты смонтировал корень btrfs или сабволюм? Там же могут быть снапшоты - сколько лишнего попадёт в архив?

Что с таром не знаю, никогда не сталкивался с ошибками даже при больших разделах. Но, сам по себе, тар в этой ситуации нужен, если временный раздел под бэкап - какой-нибудь фат или ntfs. Если же там уже какой-нибудь ext4/xfs/btrfs, то можно просто cp -ax /mnt/old_root/* /mnt/backup_root а затем cp -ax /mnt/backup_root/* /mnt/new_root/.

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

Можно, наверно, ещё тупо midnight commander’ом. Файлопомойки так переносил, корневую систему вот не знаю.

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

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

Несколько раз нарывался на то, что tar тупо пропускает часть файлов. Их просто нет в результирующем архиве. Т.е. делаешь два архива одной и той же файловой системы - размеры архивов разные, причем разница огромная, 5Гб и 3.7Гб.

Про линукс ничего плохого не могу сказать, а вот в макоси tar реально ненадёжный. Один раз бэкап с важными данными так запорол. Сделал бэкап, скопировал на диск, но не проверил. Причём размер был реалистичный. Ошибок ни на каком этапе не было. Переустановил ОС, и не смог полностью открыть архив, начиная с какого-то файла всё падало. Данные были не настолько ценные, чтобы ради них стоило заморачиваться ручным анализом архива, подумал, что диск глюкнул.

А потом гораздо позже ещё раз делал бэкап tar-ом и уже на этот раз проверил. И - ошибка. Удалил архив, опять сделал - опять ошибка. Где-то что-то глюкает.

В итоге стал делать бэкапы через 7z. С ним проблем не было.

Думал, что это bsd tar глючный (вряд ли эппл исходники правили). А оказывается и не только он…

CloneZilla в помощь, не из консоли, но все скрипты уже придумали за тебя

Вообще у тебя очень странные флаги. Флаг -c это создание архива. Для экстрашна нужен флаг -x. А ты пишешь tar -czpf /media/ubuntu/e435242657/ /media/ubuntu/backup_partition/ubuntu.tar

От греха подальше почитай ман.

Создавать архив нужно так:

cd /media/ubuntu/e435242657/ 
tar -c -f /media/ubuntu/backup_partition/ubuntu.tar *

Извлекать архив надо так:

cd /media/ubuntu/e435242657/
tar -x -f /media/ubuntu/backup_partition/ubuntu.tar

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

Также в руте обычно есть /dev в котором определённые файлы для устройств созданы. На них тоже обрати внимание, не уверен, что tar их создаст и восстановит. Ну и плюс бывают всякие странные файлы типа fifo и тп, обычно они на работающей системе создаются, но мало ли. Также надо обратить внимание, чтобы suid флаги восстановились, тоже не факт, что tar их нормально сохранит и восстановит без доп флагов.

Создал временный раздел, потом его пришлось заново пересоздавать так как файлы не поместились(в бтрфс меньше места занимают, после переноса как минимум на 10 процентов стали больше места занимать на ext4).

Скопировал с первичного бтрфс на временный ext4:

sudo rsync -avx /media/ubuntu/34534** /media/ubuntu/backup

отформатировал исходный раздел в ext4 и изменил UUID:

sudo tune2fs /dev/sda1 -U 34534**

Скопировал все с временного раздела обратно:

sudo rsync -avx /media/ubuntu/backup/34534**/ /media/ubuntu/34534**

Далее уже на новом разделе в фстаб вместо btrfs записал ext4, перезагрузка и грузится. Разделы не посмотреть, видимо из за судо, наспех сделал команду - sudo chmod 755 /media/username/

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

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

Ну дело ваше, но помнится там был пункт, просто создать архив данных

с таром у меня всегда была взаимная нелюбовь и маны я никогда не читал, такой вот я человек, с гнильцой) А все эти ключи из интернета из линукс орга…

В итоге стал делать бэкапы через 7z. С ним проблем не было.

А поделишься ключами?
У меня эмперическим путём вот такая строчка получилась но есть сомнения в её адекватности:
7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=off $DST.7z $SRC

если действительно выкинуть каменный топор tar и смотреть в современные средства, то посоветую rar, он в отличии от 7зип научился хотя в *nix параметры файла.
а лучше всего squashfs он полностью поддерживает все параметры файлов *nix

как выше упомянули rsync быстрее удобнее всего

https://docs.kernel.org/filesystems/squashfs.html#todo-list

4.1 TODO list
Implement ACL support.

Пробую открыть архив - не открывается.

Чем ты его «открыть» пытаешься? У tar нет заголовков, чтобы раз и открыть.

неважно же, так как рядом я сделал точно такой же тар бута(boot) и он открывается, распаковывается.

Нет, важно.

Но это не аргумент, так как парктически одной и той же командой я архивирую как корень / так и /boot и архив последнего открывается. Это аргумент.
Через консоль тоже самое.

Гном, проводник - если два раза кликнуть по тару то она начнет самораспаковываться.

не пользую, так что норм.

Я дефолтными настройками жал, особо не заморачивался.

rsync да, удобно и быстро но гложет немного что монтированные разделы были не видны, решение же(который я привнес в систему) - sudo chmod 755 /media/username/

Непонятно почему права изменились и только ли там они изменились!

Честно говоря я не помню какие там права были.

Как сделать файловый бекап системы?

С помощью команды dd. Первая же нагугленная ссылка на хабре даст вам всю необходимую информацию по её использованию.

дд же вроде весь раздел как есть берет? То есть работает с файлами на более низком уровне.

дд же вроде весь раздел как есть берет?

есть ключи if и of которые принимают стандартные пути, не обязательно разделы, хоть dd if=/dev/urandom of=/dev/null

C файлами dd вообще не работает, тоесть бекап одного файла размером в один байт на разделе в теробайт займёт 4 часа.
Для ssd это работает деструктивно.
Не со всеми видами файловых систем всё будет корректно, с ext4 всё хорошо, она любые издевательства стерпит, а вот два раздела btrfs c одинаковыми uuid в одной os смонтировать не получится.

C файлами dd вообще не работает

man dd:

dd - convert and copy a file
Copy a file, converting and formatting according to the operands.

Быстро скопировать информацию из одного файла в другой, это не работа с файлами, в таком режиме он даже атрибуты не может скопировать.

А зачем тебе конвертировать? Сиди себе в БТРе, понты +300, оно не падает

при чем тут понты? Там место расходуется меньше и сжатие есть.

Рррррряяя, БТР чем то хуже ext4, слышите, клоуны?

btrfs тупо медленее ext4, если фишки btrfs не нужны то зачем?

У ext4 есть сжатие? хочу. Это единственый плюс у btrfs. Тормоза lvm заставили перейти на mdadm он хоть не такой фичастый но простой и быстрый, фичи заморозки для бекапов и удобства расширения не перещеголчли скорость, тоже касается btrfs субволюумы это круто, но скорость ext4 и то что при эксплуатации больше места свободно, выгоднее.

Я иначе бы сделал:

• Сделай снапшот:

sudo btrfs sub snap -r / /path/to/@backup

• Скопируй из него файлы

sudo rsync -avh /path/to/@backup/. /target

Зачем снапшот? - Для снятия бекапа с живой системы. Я бы не советовал отказываться от Btrfs, советую отказаться от Ubuntu

Нету. Сжатие в BTRFS полезно только при хранении дампов баз данных. Например, 30-гиговый дамп ужимается до 4-х. А вот видео, картинки и тп не сжимаются, так как они и так сжатые, что для обычного пользователя в итоге даст максимум 25% экономии места, НО при использовании автоматических снапшотов преимущество Btrfs становится ультимативным

Ну как так, так мы коммунизм не построим. Обязательно всем нужно сидеть на БТР! Если не устраивает производительность - пускай пилят акселераторы, тот же NPU можно задействовать

не не не, это я использую бтрфс потому что там есть сжатие и повторяющиеся блоки файлов не повторяются

смысл в том чтобы не загружать лайв сд? А с живой системы либ мертвой.. разница? Я между прочим использую АрчЛинукс)
Убунта так посмотреть.

видео и фото у меня на файлопомойке, хранить их в бтрфс такое я считаю..
Последнее вот у меня сжатие даже не было включено а система занимала как минимум на 10% места меньше на бтрфс. Если включить там 40, может даже 50..

в бутере главная фитча CoW !! изза этого он и тормозит и много чего умеет.

если уж использовать для бекапа фитчи бутера, то стоит вспомнить что у него встроен отличный сериализатор файлов, учитывающий все фитчи бутера btrfs send btrfs receive
какие-то наметки по формированию диф.бекапов времен игорей с бутером

#!/bin/bash
# базовый срез
root_snapshot=/mnt/b11/root_base

# проверить наличие старого среза и удалить
if [ -d $root_snapshot ]
    then
    sudo btrfs subvolume delete $root_snapshot
fi

echo ------------- create r\/o snapshot --\> $root_snapshot
sudo btrfs filesystem sync /
# сделать срез в базовую папку
sudo btrfs subvolume snapshot -r / /mnt/b11/root_base

# сделать архивную копию нового среза
#                  Файл куда пишется                 дир откуда снапшот
sudo btrfs send -f /mnt/backup1/`date '+%F'`_base11 /mnt/b11/root_base
# конец

#!/bin/bash
# дифф к базовому срезу
echo ------------- create diff snapshot
sudo btrfs filesystem sync /
# сделать текущий срез
sudo btrfs subvolume snapshot -r / /mnt/b11/root_diff

# сделать архивную копию нового среза
echo ------------- send snapshot
#                  архив куда писать------------      базовый срез-----  текущий срез----
sudo btrfs send -f /mnt/backup1/`date '+%F'`_diff -p /mnt/b11/root_base /mnt/b11/root_diff

# удаляем времянку
sudo btrfs subvolume delete /mnt/b11/root_diff
# конец

У меня половину места занимают исходники:

❯ sudo compsize -x /
Processed 482091 files, 257754 regular extents (322489 refs), 266562 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       79%       29G          36G          42G       
none       100%       24G          24G          25G       
zstd        36%      4.3G          12G          17G       
prealloc   100%       20K          20K          15M       
❯ sudo compsize -x /home
Processed 957795 files, 1131679 regular extents (1158992 refs), 461938 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       68%      114G         167G         168G       
none       100%       98G          98G          98G       
zstd        23%       16G          68G          70G       
prealloc   100%       88M          88M         250M   

compress=zstd:3, его можно смело в 6-9 выставить, если не используется LUKS