dd и любые другие решения, которые копируют не файлы, а сами ФС целиком или вообще блочные устройства, можно на работающей системе применять только есть ФС примонтированы в read-only — иначе такие копии в дальнейшем неработоспособны.

Так же не следует использовать какие-либо инструменты, не предназначенные для Linux. Например, Acronis — у него есть специальная версия именно для Linux, но самая популярная и знакомая большинству — нормально работает и предназначена только для Windows, с её помощью можно делать копии Linux, но их работоспособность — как повезет.

Мне не понятно, зачем делать бекап диска такой рабочей станции по расписанию и целиком. В норме пользователь не должен иметь права root или sudo с повышением до них — то есть даже в теории он сможет порушить только свои файлы у себя в $HOME и куда ещё имеет доступ — вот их и стоит бекапить.

Проблема с отказом ЖД во время работы решается через RAID 1. А бекапы именно ОС имеет смысл делать только при обновлении компонентов ОС или изменении конфигурации — то есть при действиях, которые делать должен админ, а не пользователь. Хотя если есть автоматическое обновление... то имеет смысл и их автоматизировать.

timeshift /thread

используй снапшоты из lvm и бекапь снапшот.

Ну и вопрос — а где и на каком носителе будут храниться бекапы? Делать их на сам этот комп можно... но не очень полезно. По понятным причинам.

Как ни странно, но гноме-диск-утилити умеет в образы разделов. Насколько это работает в активной системе - не знаю, не было повода пробовать.

Резервное копирование можно делаль и от root по cron например не взирая на обычных пользователей, или я не прав?
Резервное копирование будет делаться на удаленное файловое хранилище по SMB или NFS.

Можно. Я не об этом говорил. Я не говорил о том, от какого пользователя, я говорил, что копировать.

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

разделяй и властвуй - система на отдельном разделе, bpvtyztvst данные на другом (/home имеется ввиду).

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

бекап данных обычным файловым архиватором при отключенных клиентах 1с.

Я не понимаю вас, советчики про dd. Вы глупые? Допустим винт на 1 Тб. Юзер накачал пол диска фильмов а потом удалил. Сколько займет бакап? Ага, 0.5 Тб. Секторы то не обнуляются при удалении файла.

По подробней пожалуйста, почему Acronis не годится для Linux?

Я о его версии для Windows. Если вкратце, делая образ диска, он для экономии места сжимает ФС. На NTFS, FAT32 и exFAT его алгоритмы рассчитаны. А на ext4, XFS, LVM и прочие Linux технологии (долго все перечислять) — нет. Как следствие, могут возникать ошибки при обратном разжатии. Могут и не возникать, но это как повезет.

И это будет использование ПО так, как его создатели не рассчитывали. ПО для бекапов Linux тестируется на успешную работу с ним. Acronis для Windows — нет. То есть любой случай такого его применения — это упование на удачу. Это просто неправильно — уповать на удачу и забивать шурупы молотком потому, что не умеешь пользоваться отверткой. Надо учиться. Даже если «пока работает».

Рабочая станция бухгалтерская с 1С. Резервное копирование необходимо делать когда пользователь в ней работает. Нужна полная резервная копия всего системного жесткого диска, что бы не пришлось перенастраивать все при сбое. Осуществлять резервное копирование по расписанию.

Таких средств в Linux нет.

Как выше говорили отдели систему и данные, например в /home, /var.

Резервную копию системы в GNU/Linux создают tar или squashfs. Хранят на CD/DVD или другом диске. Обновляют после измерений или обновлений.

/tmp, /var/tmp, /mnt, /dev, /run, /proc, /sys - не бекапят.

/home, /var бекапить можно по cron. Перед бекапом его перемонтируют с опциями atime, нельзя наличие опций типа noatime, relatime, lazytime перемонтируют ro может не дать; останавливают все что можно и делают sync /home /var. Все зависит от того что у тебя в /home, /var можно логи отдельно по сети собирать, подобно и другие сервисы. Базы и прочие, включая 1C имеют свои спец инструменты для создания гарячего снапшота и необходимо использовать только их.

Btrfs уже рекомендовали?

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

А даш гарантию, что снапшота/дамп btrfs (в режиме rw) будет содержать корректный файл базы 1C?

Сколько займет бакап? Ага, 0.5 Тб.

После dd 1Tb диска бэкап займёт 1Tb :)

Если сжимать, то перед бэкапом надо на разделе создать файл с нулями размером во всё свободное место, а потом его удалить. Очевидно, что это крайне неудобно. Поэтому не стоит использовать dd для бэкапа.

••••••••••••

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