"Снэп" используем мы. Но вот каким образом.
Основные дисковые ресурсы расположены на дисковом массиве ЕМС.
И уже дисковый массив умеет делать SNAPSHOT.
- всё дисковое пространство массива делится на LUNы (логические юниты)
- LUNы закрепляются за серверами. сервер видит LUNы как физические диски. Их делим на разделы, затем на тома....
- массив умеет делать "клон" LUNа, "снеп" LUNа, "клон" "снепа"
- "клон" - это полная копия LUNа, занимает какоето время, зависит от объёма LUNа.
- "снеп" - это ПРОЦЕСС, протекающий на массиве с момента его активации до момента деактивации.
- и "снеп", и "клон" можгут быть закреплены за сервером. Сервер увидит новые дисковые тома (если имена не дудут конфликтовать)
Так вот, механизм работы "снэпа":
- на момент активации массив резервирует место на своих дисках (не в пределах LUNа) примерно 20% от размера LUNа. Там он хранит изменения LUNа. И "снэп" представляет из себя реальный LUN + "резерв"
- массив перед тем как записать измененившийся блок на LUNе, переписывает старое состояние блока с LUNа в "резерв", затем пишет в LUN изменения и запоминает что было изменено.
- таким образом данные на "снэпе" выглядят не изменяемыми. Можно бакапить хоть до посинения. Но данные там будут на момент активации "снэпа".
Ньюансы:
- для подддержания актуальности данных "снэп" необходимо переодически пересоздавать.
- если используются БД типа "фокса", "клиппера", "д-Базе"

на момент создания "снэпа" файлы на LUNе всё-таки должны быть закрыты, т.к. процесс активации растянут во времени (секунды, но и за это время могут наизменять файлы - целостность БД уже на "снэпе" может нарушиться).
- в случае восстановления данных, мы получим состояние на момент активации.
Вот кратенько как оно работает. В других системах примерно также (я думаю)...
принцип IBM: Машина должна работать - человек думать

Хорошие вести: - все файлы на месте.