Подскажите, какой вариант для бэкапа лучше выбрать?

1.FLOSS 2.Имеется LiveCD/LiveDVD/LiveUSB с данной программой. 3.Умеет сжимать данные. Желательно, чтобы поддерживалось разнообразные алгоритмы и степени сжатия. 4.Умеет инкриментальный бэкап 5.Умеет отдельно сохранять MBR, таблицу разделов и т.п. . 6.Во время записи резервной копии удостоверяется, что все данные правильно записались на носитель. Уже записанные данные имеют checksum'ы, поэтому даже если ошибка возникнет после записи, это будет заметно. 7.Умеет делать полную копию диска или его разделов а-ля dd. 8.Умеет добавлять избыточную информацию для восстановления, а-ля WinRAR.

1,2,3,4,6 — tar

5,7 — tar+dd (собственно dd нужна лишь для сохранения MBR и таблицы разделов)

И да, это всё годно linux only, венду не получится. За то можно прямо на лету, без остановки. (конечно такие вещи как СУБД следует бекапить специальными методами)

8 — par2

И да, это всё годно linux only, венду не получится.

А у меня Windows нет, так что это не мои заботы.

1,2,3,4,6 — tar

Боюсь Вы меня не поняли. Я конечно могу написать скрипт с использованием tar/dd/сpio и т.д., но ради экономии времени и усилий я сейчас ищу программу в стиле «нажал и готово».

За то можно прямо на лету, без остановки.

Да ну, каким образом? Ведь содержания работающего диска все время меняется, как может быть возможно создать точный бэкап без перевода в режим read-only ?

Боюсь Вы меня не поняли. Я конечно могу написать скрипт с использованием tar/dd/сpio и т.д., но ради экономии времени и усилий я сейчас ищу программу в стиле «нажал и готово».

вот как раз для экономии времени и нервов — напишите скрипт. А не занимайтесь онанизмом. Как всегда — ИМХО.

Да ну, каким образом? Ведь содержания работающего диска все время меняется, как может быть возможно создать точный бэкап без перевода в режим read-only ?

в два приёма:

1. делается полный бекап (без сжатия)

2. проверяется cksum, если изменилось, то tar --append. Этот пункт нужно в цикл завернуть. Кроме того, некоторые файлы отсюда нужно исключить. Например логи(не обязательно _самую_ последнюю версию бекапить) и СУБД (как я уже сказал, для этого есть спецсредства, которые и нужно использовать)

Причём это всё реализовано в tar'е без дополнительных костылей. Разве что там не CRC32, а timestamp. Что ИМХО ещё и лучше(можно например засунуть в бекап файл просто изменив его timestamp, это годно, если вы желаете сохранить файлы обязательно в инкременте, даже если они не менялись, например для того, что-бы быстро их извлечь)

tar также поддерживает многотомные архивы, что позволяет обойтись без их резки (резка нужна для par2). При этом _каждый_ том представляет собой полноценный архив, и потому вы можете при желании извлекать только некоторые файлы(конечно неплохо для этого сохранить карту бекапа, просто список всех файлов в томе)

А пример можно с п4. и tar?

4.Умеет инкриментальный бэкап

А пример можно с п4. и tar?

File: tar.info,  Node: Incremental Dumps,  Next: Backup Levels,  Prev: Full Dumps,  Up: Backups

5.2 Using `tar' to Perform Incremental Dumps
============================================

"Incremental backup" is a special form of GNU `tar' archive that stores
additional metadata so that exact state of the file system can be
restored when extracting the archive.

   GNU `tar' currently offers two options for handling incremental
backups: `--listed-incremental=SNAPSHOT-FILE' (`-g SNAPSHOT-FILE') and
`--incremental' (`-G').

Но сейчас ТС отредактировал свой пост, и теперь п4 звучит иначе. ИМХО это случай «специальных файлов/каталогов». ИМХО следует например использовать DVCS, и бекапить каталоги с DVCS отдельно, средствами этой DVCS. К примеру, если используется mercurial, следует обходить стороной все каталоги с подкаталогом ./.hg, и сохранять их в отдельный бэкап командой hg bundle. Эта команда создаёт «банку» с нужными ревизиями. Т.е. если прошлая банка имела ревизию XYZ, то следующая создаётся командой hg bundle --base XYZ. При этом получается именно то, что и хочет ТС — если в файле дописалась лишняя строчка, то в банку добавится только эта строчка.

Делать такое для всех каталогов нельзя, ибо поиск «лишней строчки» в каком-нить фильме повесит напрочь самый мощный компьютер. Для фильмов и прочего такого версионность если и нужна, то лишь на уровне файлов а не diff'ов.

вот как раз для экономии времени и нервов — напишите скрипт.

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

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

если вам нравятся такие аллегории, то давайте устроим соревнование: Я живу в центре СПб, мы едем в лабаз за шампанским победителю, и обратно. Вы на Бугатти Вероне, я на велосипеде «Украина». Кто победит — вполне очевидно. Я уж молчу про ваши расходы хотя-бы на бензин.

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

И да, идеального метода бекапа попросту не существует, всё множество файлов можно поделить на несколько категорий, для каждой из которых нужен исключительно _свой_ метод бекапа. Причём методы настолько разнообразные, что воткнуть их в свою программу в принципе невозможно. Или вы собрались велосипедить свою DVCS и свою *sqldump? Ага, и ещё своё недошифрование, устойчивое лишь против олигофрена в стадии дебильности. Коды Рида-Соломона и преобразование Барроуза-Уилера тоже сами будете велосипедить? Не хотите? Тогда у вас два варианта:

1. слепить нефункциональное говно по типу WinRAR (да, было годно в 1995ом, но уже столько лет прошло...)

2. велосипедить свой скрипт, используя готовые unix way утилиты (ВНЕЗАПНО: лучше всех шифрует данные gpg, которая кроме этого более ничего и не умеет. No Way).

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

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

всё зависит от требований, которые предъявляются к бекапу. Если хочется МБР бекапить dd, и ПРИ ЭТОМ ещё и похожие строчки отлавливать и хранить только их diff, то без индивидуальной настройки каталогов просто не получится. Бекапилка должна знать, где и что у неё лежит, если требования настолько противоречивы, как у ТСа.

Не понимаю, а в чем противоречие?

Не понимаю, а в чем противоречие?

противоречие в том, что не существует(к сожалению) хрустального шара, в который можно заглянуть, и понять, что это за файл, и как его бекапить. Я вот сейчас голову ломаю, что делать с файлом .mozilla/firefox/*.default/cookies.sqlite, размером полметра, который каждые 2 минуты меняется? Не, я могу конечно задать для него специальные правила(а какие?), но это же полумера...

А зачем Вам заморачиваться с каждым отдельным файлом, место экономите, пытаетесь только важные файлы сохранить? У меня лично такой проблемы нет, так как места на диске более чем достаточно.

А зачем Вам заморачиваться с каждым отдельным файлом, место экономите, пытаетесь только важные файлы сохранить? У меня лично такой проблемы нет, так как места на диске более чем достаточно.

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

батарейка быстро кончается

Ну для меня это опять-таки не проблема. Хоть у меня и ноутбук, но использую его в качестве стационарного ПК.

Во первых тормозит

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

Да ну, каким образом? Ведь содержания работающего диска все время меняется, как может быть возможно создать точный бэкап без перевода в режим read-only ?

Можешь использовать LVM, создаешь снапшот, и можешь спокойно смотреть «замороженные» файлы.

Вы уж простите чайника, но просто как, чисто технически, создается этот снапшот? Ведь чтобы он был 100% соответствовал состоянию системы в тот момент времени, надо на некоторое время заморозить любые изменения в файловой системе и в самих файлах. Если такой заморозки не происходит, то мне было бы крайне интересно узнать, за счет чего это достигается. Ибо я этого АБСОЛЮТНО НЕ ПРЕДСТАВЛЯЮ.

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

real 0m7.326s

Сколько места на диске занимают системные файлы?

основная часть 30Мб, инкремент 265К.

Для сравнения, у меня система занимает 9 гигабайт.

WOW! Эксклюзивная постоянно пополняемая коллекция домашнего порно! Давай так: ты со мной делишься порнухой, а я тебе делаю систему бекапа. По рукам?

Вы уж простите чайника, но просто как, чисто технически, создается этот снапшот?

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

Этот тип устройства представляет собой доступную только на чтение (при использовании опции --permission r) копию другого тома на момент выполнения процедуры «снапшот». Это дает возможность продолжать работу не заботясь о том, что данные могут измениться в момент резервного копирования. Следовательно, нам не нужно останавливать работу базы данных на время выполнения резервного копирования. Остановка нужна только на момент создания устройства-«снапшот», который значительно короче самого копирования.

http://xgu.ru/wiki/LVM

Когда ты делаешь снапшот, то логический том продолжает работать так же, в прежнем режиме. Можешь попробовать сам, не обязательно сразу систему пересаживать. Создаешь физический том в виде файла, в нем группу томов, в группе - логический том. Потом его форматируешь под любимую ФС,монтируешь, записываешь данные. Затем, создаешь снапшот, его монтируешь в другое место, и пробуешь удалить на оригинальном томе файлы. А на снапшоте эти файлы останутся.

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

real 0m7.326s
основная часть 30Мб, инкремент 265К.

Ой, что-то какие-то нереальные числа пошли ...

WOW! Эксклюзивная постоянно пополняемая коллекция домашнего порно!

Минуточку, я говорил об СИСТЕМНЫХ файлах! Это у меня столько весит вся система целиком.