Нормальный способ забэкапить программы вместе с настройками

Хомяк бэкапишь целиком и всё.

Очень смешно.

Купи 8-террабайтник и бэкапь (сжато) всю систему кроме файло в хомяке.

Например:

tar -cf - --numeric-owner --exclude=swapfile home/my_user/snap --exclude='home/my_user/.cache/*' --exclude='home/my_user/[^.]*' . | pigz -9 > /mnt/sdb1/backup.tar.gz

По этому сценарию у меня выходит:

-rw-r--r--  1 root root 8,2G Aug 18 05:19 full.tar.gz
-rw-r--r--  1 root root 4,7K Aug 18 05:20 file.acl
-rw-r--r--  1 root root 5,6K Aug 18 05:20 file.attr
-rw-r--r--  1 root root  332 Aug 18 05:21 commandline.txt

exclude

Ой всё

Бекапишь ~/.local и ~/.config.

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

~/.local

Лучше ~/.local/share (он же XDG_DATA_HOME), потому что в ~/.local может быть много лишнего мусора с точки зрения бэкапов (~/.local/bin, ~/.local/lib)

1. Складываешь конфиг NixOS (c Home Manager) в гит.
2. ???????
3. PROFIT!

Зачем бэкапить систему я не представляю, её за 5 минут можно поставить с нуля из пакетов, а за 2 часа вообще собрать из исходников. Достаточно бэкапить хомяк и /etc.

А как в онтопике это принято делать по-нормальному?

И почему же этот rsync это не по-нормальному?

Очень смешно

Опять, что не так-то?

Могу только ванговать, а наванговать могу только одну причину - там есть какое-то большое файло которое не хочется бэкапить. Тогда это хороший вопрос и я до сих пор не знаю как в лилихах с этим живут, а у меня на FreeBSD есть замечательный флаг файловой системы nodump. Достаточно сделать chflags nodump на всё что не нужно бэкапить, и потом tar -c --nodump не будет включать это в архив, а du -n покажет размер будущего бэкапа без учёта исключённого (и им же можно искачать что ещё выкинуть). Без поддержки этого флага я бы наверное сделал файл со списком exclude путей. Может это даже и более наглядно где-то.

Держать в гитлабе-паппете.

Врубаешь impermanence, при загрузке NixOS пересоздаст.

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

~/.vimrc и ~/.vim ~/.bashrc, ~/.zshrc ~/.muttrc, ~/.mutt ~/.gitconfig

Ну да.

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

у меня скриптом реализовано. как для бэкапа, так и для миграции конфигов между системами (директориями).
просто есть файл-список того, что нужно сделать (переносить):
...
cp -a "$src_ROOT/etc/ports/" "$dest_ROOT/etc/"
cp -a — "$src_ROOT/etc/X11/" "$dest_ROOT/etc/"
...
cp -a — "$src_ROOT/usr/lib/locale/locale-archive" "$dest_ROOT/usr/lib/locale/"
...
запускаю просто > mig / /dest_dir/ оно подтягивает нужный файл с тем что нужно выполнить

Зачем бэкапить систему я не представляю, её за 5 минут можно поставить с нуля из пакетов, а за 2 часа вообще собрать из исходников.

Ну, во-первых, за 5 минут ты поставишь разве что базовую версии Рача, если все поместишь в скрипт. Десктопные дистрибутивы ставятся довольно долго. Кроме того, если схема разделов сложная (lvm, несколько разделов, дулбут etc), то прибавляются дополнительные головняки все правильно смонтировать и ничего не затереть. Скажем, на подготовку и переустановку системы я бы отвел не менее получаса.

А с последующей установкой и настройкой программ – часа два. И после этих двух часов ты уже потратил все мыслетопливо и день, считай, прошел зря.

Во-вторых, как определить, что систему нужно переустанавливать? Какой-то один пакет сломался – будешь переустанавливать? А если после обновления месы или драйверов видишь черный экран? Переустанавливать?

Зачем бекапить конфиги я понимаю. Зачем бекапить бинари?

А товарищ дело говорит. Хомяк - это самое ценное и лучше его бэкапить весь. Из системных вещей мне всегда хватало бэкапов /etc и /var/lib/dpkg чтобы привести систему в изначальное состояние на пару часов.

Для этого говна можно сделать симлинки и хранить все в одном месте.

Так я не про бэкап системы, а про бэкап программ. Хомяк бэкапится выборочно и разными способами, тут ни о какой автоматизации речи быть не может, это понятно. Но да, /etc и скрытые папки в хомяке - это самое ценное что есть в программах. Плохо только что оно по разным каталогам лежит, а при этом личные файлы и настройки программ - в одном каталоге. И еще эти настройки в хомяке надо вручную отделять от не настроек - от всякого кэша NPMа и прочего.

Хотя систему бэкапить - тоже ничего плохого нет. Сервера не вечные, интернет не бесперебойный, и с локального носителя восстановить всегда быстрее, чем перекачать, skiminok1986, bugfixer.

Опять, что не так-то?

Это троллинг такой? Типа необходимость вручную что-то там сортировать по размеру и отмечать флагами - это норма? Тем более надо отделить не большое, а то, что не является частями приложений.

teod0r пишет:

просто есть файл-список того, что нужно сделать

А файл этот я где должен взять? Это ж не по-нормальному, а с учетом кривизны существующего. Это только подтверждает, что это не моя шиза, а оно реально кривое.

~/.mozilla намного удобнее чем искать её куски по .local и .config не говоря уж о том что профиль можно в кастомное место вообще класть

theNamelessOne, t184256, прочитал, ничего не понял. Там можно сделать корень и /home в памяти, и чтобы симлинки из них смотрели на настоящие файлы, которые могут лежать уже как-то по-другому?

А файл этот я где должен взять?

сам создать конечно же. кто кроме тебя знает, что нужно бэкапить, а что — нет? один раз прописал нужные строчки и пользуйся сколько угодно.

Что нужно бэкапить - в заголовке. Я сам должен только кнопочку нажать.

Там можно

Да.

one@ddidwyll ~> mount
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1225560k,nr_inodes=3060666,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=3,mode=620,ptmxmode=666)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,size=12255572k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=6127788k,mode=755)
ramfs on /run/keys type ramfs (rw,nosuid,nodev,relatime,mode=750)
tmpfs on /run/wrappers type tmpfs (rw,nodev,relatime,size=12255572k,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
none on / type tmpfs (rw,relatime,size=5242880k,mode=755)
/dev/nvme0n1p2 on /nix type ext4 (rw,relatime)
/dev/nvme0n1p2 on /var/lib type ext4 (rw,relatime)
/dev/nvme0n1p2 on /var/log type ext4 (rw,relatime)
/dev/nvme0n1p2 on /nix/store type ext4 (ro,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p2 on /etc/NetworkManager type ext4 (rw,relatime)
/dev/nvme0n1p2 on /etc/nixos type ext4 (rw,relatime)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=2451112k,nr_inodes=612778,mode=700,uid=1000,gid=100)
/nix/persist/data/images on /home/one/images type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Xfceterm/.config/xfce4/terminal on /home/one/.config/xfce4/terminal type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Erlhist/.cache/erlang-history on /home/one/.cache/erlang-history type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/music on /home/one/music type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/docs on /home/one/docs type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Edge/.config/microsoft-edge on /home/one/.config/microsoft-edge type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/videos on /home/one/videos type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Kakoune/.config/kak on /home/one/.config/kak type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/tmp on /home/one/tmp type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Mix/.mix on /home/one/.mix type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Brave/.config/BraveSoftware on /home/one/.config/BraveSoftware type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Teeldeer/.cache/tealdeer on /home/one/.cache/tealdeer type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Postman/.config/Postman on /home/one/.config/Postman type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Hubstaff/.local/share/HubStaff on /home/one/.local/share/HubStaff type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Bin/.local/bin on /home/one/.local/bin type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Amixer/.ncpamixer.conf on /home/one/.ncpamixer.conf type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/wrk on /home/one/wrk type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/data/share on /home/one/share type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Telegram/.local/share/TelegramDesktop on /home/one/.local/share/TelegramDesktop type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)
/nix/persist/dotfiles/Ssh/.ssh on /home/one/.ssh type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions,allow_other)

Если что-то лежит в /opt/, то и его так же скинуть.

Зачем оно тебе в переустановленной системе, оно же мимо пакетного менеджера будет.

Ну а хомяк и правда лучше целиком, а то что из хомяка не нужно(например файлопомойка), то это хранить отдельно, а в хомяк симлинками.

Одна из идей NixOS — это то, что твоя система полностью описана в виде nix-конфига. В этом конфиге содержатся список установленных программ и их версии, из него генерируются конфиги системных сервисов и утилит (которые в /etc) и конфиги пользовательский программ (которые в хомяке). Этот nix конфиг можно (и нужно) хранить в системе контроля версий, что должно полностью покрывать твой юз-кейс без нужды в ручном бэкапе — в случае необходимости ты просто можешь развернуть с нуля этот конфиг на новом железе, получив готовую систему с необходимыми тебе уже настроенными программами.

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

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

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

Не знаю, как в других DE, но я для Гнома прописываю dconf-настройки в конфиге NixOS.

AppImage в режиме portable или GoboLinux.

Все так и управлялись нормальной системой управления конфигурациями.

Типа необходимость вручную что-то там сортировать по размеру и отмечать флагами - это норма?

В случае если не хочешь бекапить все - да. Никто не знает за тебя, какие файлы надо бекапить. Процесс можно немного упростить, если завести отдельную директорию для файлов которые бекапить не надо. У меня в эксклюде ~/Downloads со всякими фильмами и прочим скачанным барахлом, которое имеет малую ценность или легко восстанавливается.

Ну и перед бекапом запускаю ncdu чтобы проверить, что ничего не выросло и не надо ли что-то новое добавить в exclude

Как же я люблю AppImage! Оказывается, можно и настройки рядом с ним положить. Но обычно-то программы не в AppImage. Что им $HOME кастомный делать? Так ведь не всё, что в хомяке - настройки. Игры в Стиме - это данные, кэш NPM - это данные. Я думал, может что-то в самих стандартах предусмотрено, чтобы настройки, данные, состояние и другое разделить по смыслу. А тут по сути в хомяке «пользовательские /etc, /var и /opt».

Но обычно-то программы не в AppImage

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

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

Нет. FHS — архаизм. На desktop'е давно нужно было сделать так, как сделали в macOS или GoboLinux.

Ну, во-первых, за 5 минут ты поставишь разве что базовую версии Рача, если все поместишь в скрипт. Десктопные дистрибутивы ставятся довольно долго. Кроме того, если схема разделов сложная (lvm, несколько разделов, дулбут etc), то прибавляются дополнительные головняки все правильно смонтировать и ничего не затереть. Скажем, на подготовку и переустановку системы я бы отвел не менее получаса.

Я не знаю как у вас там в линуксах, во FreeBSD установка системы это 2 минуты, в установщике нужно разве нажать next на ~5 экранах, выбрать разве что ZFS разметку диска ну и флажки снять с ненужных дистрибуций оставив только base и kernel. Потом он распаковывает базовую систему и ядро, это сотни мегабайт, поэтому весь этот этап ~ минута. Потом можно загрузиться в систему и сделать pkg install <список пакетов>. Тут в зависимости от сети может и дольше - ну пусть 10 минут. Но никакого интерактива не нужно.

А с последующей установкой и настройкой программ – часа два. И после этих двух часов ты уже потратил все мыслетопливо и день, считай, прошел зря.

У тебя же забэкаплен хомяк, не нужно ничего настраивать. Только tar xzf набрать.

Во-вторых, как определить, что систему нужно переустанавливать? Какой-то один пакет сломался – будешь переустанавливать? А если после обновления месы или драйверов видишь черный экран? Переустанавливать?

Для этого не нужны бэкапы, для этого есть снапшоты ZFS. Бэкапы нужны когда у тебя сгорела хата вместе с диском и систему таки надо переустанавливать.

Но да, /etc и скрытые папки в хомяке - это самое ценное что есть в программах

Это к программам вообще не имеет отношения. Это твои личные данные.

Хотя систему бэкапить - тоже ничего плохого нет. Сервера не вечные, интернет не бесперебойный, и с локального носителя восстановить всегда быстрее, чем перекачать

Формально конечно да, но по мне так сервер без сети никакого смысла восстанавливать нет. Алсо, персистентные серверы это архаика, сейчас сервер это ansible playbook, который можно развернуть ещё быстрее чем за те 5 минут хоть на на другом хостинге хоть на другом железе не думая вообще что что-то там нужно будет перенастраивать.

Это троллинг такой? Типа необходимость вручную что-то там сортировать по размеру и отмечать флагами - это норма?

Епть, а как иначе-то? Кто должен за тебя решить что тебе бэкапить, а что нет, если ты не хочешь бэкапить всё? Сортировка по размеру - самый простой способ выкинуть самое большое ненужное, не закапываясь в разметке мелкого. Посмотрел du, увидел что в топе кино, порнуха и кэш мозиллы, поставил на них nodump, получил бэкап который влезает на дискету, счастлив.

Это к программам вообще не имеет отношения. Это твои личные данные.

Нет, это настроенные программы.

Кто должен за тебя решить что тебе бэкапить, а что нет, если ты не хочешь бэкапить всё? Сортировка по размеру - самый простой способ выкинуть самое большое ненужное, не закапываясь в разметке мелкого.

Ну если бы бардака не было, то оно было бы как-то отделено по смыслу, а не по размеру. Настройки надо бэкапить, даже если они большие, а thumbnails не надо никогда. Кино в эпоху SSD на /mnt/hdd/Видеотека. Можно вообще два хомяка сделать - один для файлов, которые создаются и качаются вручную, а другой - чисто технический - куда программы что-то пишут, только это не избавит от бардака в этом «техническом хомяке».

а что, так можно было?! а как же пердолинг?!

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

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

Ну я бы хотел drag & drop каталог с программами и всё. А в Андроиде почти так. Там хоть и приложения могут что-то произвольное сохранять в карту памяти, по-хорошему настройки они должны хранить в /data/data.

Unixson, а как в том юниксе будущего эта проблема будет решаться?

Только костылить скрипты самому

Я сейчас пересел на vanilaOS и там есть утилита для бекапа рабочего окружения. Правда работает она только с flatpak. Но я может быть не совсем правильно понял месседж твоего поста конечно, но все равно вот https://flathub.org/ru/apps/io.github.vikdevelop.SaveDesktop

Кстати как вариант могу предложить OSTree для хранения конфигов и пользовательских настроек в этаком «git-подобном» хранилище. Но оно с одним отличием. Оно умеет в бинарный diff. Т.к например возможны случаи когда приложение хранит свои конфиги в бинарном виде. Вот и все.

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

А там можно настроить так чтобы хоть в облако это пушить либо локально на другом диске держать. МБ даже отдельный раздел под это заиметь чтобы в случае комы ОС переподнять все одной командой/кнопкой.

Я бы так сделал.

А делать бы это не пришлось если бы архитекторы дистрибутивов договорились и ввели жесткий контроль над конфигами. Возможно ввиде какой нибудь директории аля /Users/Settings и сделали бы так чтобы только туда приложения могли писать свои потроха.

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

Я не пойму, а где приложения хранят свои настройки в этой ОС?

Но я может быть не совсем правильно понял месседж твоего поста конечно

Мессадж в том, что настройки лежат бардаком вперемешку с thumbnails и подобным мусором, да еще и на разделе вместе с личными файлами. Это ладно бы, можно личные данные хранить не в хомяке, а где-то еще, но меня бесит это .[^.]* и вообще то что это в консольке надо делать, и то что куча исключений, которые вручную надо прописывать. А я хочу drag'n'drop папку с программами и всё. Либо нажать кнопку в утилите, которая мне сохранит на другом разделе тарбол с моими программами и их настройками. Я просто чувствую плохой дизайн, что я решаю проблемы, которых не должно существовать.

А там можно настроить так чтобы хоть в облако это пушить либо локально на другом диске держать. МБ даже отдельный раздел под это заиметь чтобы в случае комы ОС переподнять все одной командой/кнопкой.

diff'ы бэкапов это прикольно, но это можно и сейчас, тут и обычный git пойдет. У меня бэкапы на другом физическом диске внутри компа и еще на флешке. Надо еще на Я.Диск положить, чтобы точно правило 3-2-1 выполнялось.

Я не пойму, а где приложения хранят свои настройки в этой ОС?

В /Users/<user_name>/Settings/<имя пакета>

Например /Users/Unixson/Settings/com.google.Chrome

Там и только там. Если приложение попробует писать куда-то еще, то должно получать лопатой по хрептине. А в манифесте указывать доступы которые приложение хочет получить по-мимо стандартных.

А я хочу drag’n’drop папку с программами и всё

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

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

Аминь брат. Я про тоже самое говорю уже не один тред. Единственный выход сейчас это написать какую-то гуевую утилиту для того чтобы она собирала тарболы с настройками игнорирую ту чушь которую в home пишет сам дистрибутив, вроде кешей и прочего говна. Ибо то как сейчас линукс работает с настройками программ пользователя это курам насмех. Это надо переделывать.