LINUX.ORG.RU

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

 


0

3

Ubuntu 24.04 на бтрфс и задача изменить файловую систему на ext4.
Гуглим и узнаем что конвертировать нельзя а находим статью отсюда же Как сконвертировать btrfs в ext4 без потери данных?

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

tar -czpf /<точка монтирования корня> <имя архива>

Подставляю свои данные:

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

И ошибка, пришлось изменить очередность написанного(и судо еще добавить):

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

И вроде пошел процесс, в процессе консоль показал - несколько socket ignored и Removing leading `/’ from hard link targets.

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

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

sudo tar -czpf /media/ubuntu/backup_partition/test.tar /media/ubuntu/e435242657/boot/

Как сделать файловый бекап системы? Еще раз попробовать как выше и снова ждать?

★★

Последнее исправление: Dimez (всего исправлений: 1)

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

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

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

Стал юзать rsync

Chord ★★★★
()
Последнее исправление: Chord (всего исправлений: 1)

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

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

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

Sapetuko ★★
() автор топика

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

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

pfg ★★★★★
()
Ответ на: комментарий от Sapetuko

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

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

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

Sapetuko ★★
() автор топика

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

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

altwazar ★★★★
()
Ответ на: комментарий от NyXzOr

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

Sapetuko ★★
() автор топика
Ответ на: комментарий от pfg

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

Sapetuko ★★
() автор топика
Ответ на: комментарий от Chord

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

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

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

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

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

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

Вообще у тебя очень странные флаги. Флаг -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 их нормально сохранит и восстановит без доп флагов.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 4)

Создал временный раздел, потом его пришлось заново пересоздавать так как файлы не поместились(в бтрфс меньше места занимают, после переноса как минимум на 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/

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

Sapetuko ★★
() автор топика
Ответ на: комментарий от Silerus

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

Sapetuko ★★
() автор топика
Последнее исправление: Sapetuko (всего исправлений: 2)
Ответ на: комментарий от vbr

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

Sapetuko ★★
() автор топика
Последнее исправление: Sapetuko (всего исправлений: 2)
Ответ на: комментарий от vbr

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

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

quad
()
Ответ на: комментарий от vbr

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

pfg ★★★★★
()
Ответ на: комментарий от MagicMirror

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

Sapetuko ★★
() автор топика
Последнее исправление: Sapetuko (всего исправлений: 1)
Ответ на: комментарий от MagicMirror

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

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

Sapetuko ★★
() автор топика
Последнее исправление: Sapetuko (всего исправлений: 2)
Ответ на: комментарий от s-warus

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

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

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

Sapetuko ★★
() автор топика
Последнее исправление: Sapetuko (всего исправлений: 1)
Ответ на: комментарий от Sapetuko

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

s-warus ★★★
()
Последнее исправление: s-warus (всего исправлений: 2)
Ответ на: комментарий от Sapetuko

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

s-warus ★★★
()

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

  • Сделай снапшот:
sudo btrfs sub snap -r / /path/to/@backup
  • Скопируй из него файлы
sudo rsync -avh /path/to/@backup/. /target

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

rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от s-warus

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

rtxtxtrx ★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от s-warus

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

DumLemming ★★★
()
Ответ на: комментарий от rtxtxtrx

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

Sapetuko ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

в бутере главная фитча 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
# конец
pfg ★★★★★
()
Ответ на: комментарий от Sapetuko

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

❯ 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

rtxtxtrx ★★
()