Софт для бэкапа (посоветуйте)

[Vertigo]

Кто может что подсказать по сабжу?
Главный критерий - во время бэкапа файлы не должны изменяться. Ситуация - есть приложение, которое часто изменяет файлы, поддерживая внутри себя какую-то транзакционность, поэтому бэкап должен содержать срез файловой системы на определенный момент времени. Поэтому не подходят просто tar и т.д.
Есть ли такое в принципе?

[Cap. J2A]

Vertigo, не поможет срез ФС. В принципе, можешь попробовать freeze -- фишка LVM. Но я сомневаюсь, что выгорит. Надо вначале весь кеш сбросить, и тогда любым инструментом. Тем же tar-ом или dump-ом.

[Nab]

Есть вот такая замечательная штука, может она поможет :

CHPOX - CHeckPOinter for linuX
==============================

Copyright © 2002, Olexander O. Sudakov <csaa@mail.univ.kiev.ua>
Copyright © 2002-2004, Eugeniy S. Meshcheryakov <eugen@univ.kiev.ua>

This program licensed under the GNU General Public License. See COPYING for
more details.

-----------------------------

CHPOX is a set of the Linux kernel modules for transparent dumping of
specified processes into disk file and restarting ones.

FEATURES
========

Dumping of one process or process with all it's children into disk file.
Restarting of process or group of processes from file.
CHPOX supports dumping of virtual memory, regular files,
current working directory, pipes, Unix sockets, multiple non-interacting
processes.
It does not crush on openMosix [3], it is SMP safe.
It works as a kernel module, so you does not need recompilation of the
Linux kernel.
Supports i386, ppc and s390/s390x architectures.

---------Readme---skipped---------------------------

LINKS
=====

1. http://www.chechpointing.org/ Checkpointing.org: The home to checkpointing packages
2. http://www.beowulf.org/software/bproc.html BPROC: Beowulf Distributed Process Space
3. http://www.openmosix.org/ The openMosix Project

[Vertigo]

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

[alv]

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

PS и ни tar, ни dump, ни что иное не могут гарантировать от того, что в момент бэкапа кто-то не редактирует архивируемые тексты, например

[Vertigo]

alv , я собственно и ищу программу с фукциональностью снапшота. Принцип ее действия, как я понимаю, заключается в установке локов на все копируемые файлы (flock?), а дальше хоть таром. У используемой фс gfs нет возможности делать снапшот на уровне фс.
Остановить работающее приложение нельзя, кроме того, ему нужно ему оставить возможность читать файлы. Смириться с тем, что бэкап будет неконсистентным тоже нельзя, из-за логики работы приложения такому бэкапу место на помойке...

[kolyan]

Проблема решается с помощью механизма мгновенных копий ФС (shaphot). Такой механизм, поддерживается, к прмеру, в FreeBSD 5-ой линейки. Подробнее здесь:

http://www.freebsd.org.ru/handbook/snapshots.html

В других серверных ОС тоже имеется поддержка этого механизма.

[alv]

2Vertigo
Теперь понял - речь идет о средстве для создания снапшотов, независимого от файловой системы, в т.ч. и для файловых систем, такую возможность от роду не поддерживающих
Правильно?
Увы, не знаю. Знаю только системы, у которых это штатная функция - UFS2, как сказал kolyan, JFS - это их фирменная фича была с самого начала, LVM
А про GFS, к сожалению, не знаю ничего кроме названия

[Vertigo]

alv , да правильно. Вообщем-то именно для gfs ищу, поскольку альтернативы ей (gfs) у нас пока нет.
kolyan , в RHEL4 этого нет