Elen Lebenstein,

бэкап да, может "детектировать" некоторые повреждения БД, но не все.
http://www.ibase.ru/db_repair#norestore
так что рестор этого бэкапа может не пройти, а "починить" бэкап нельзя.
В общем, после бэкапа надо сделать контрольный рестор, и уже готовую базу "отправить в хранилище". А бэкап - либо оставить, либо выкинуть.

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

1. после тестового рестора база уже есть, время на рестор потрачено. С учетом того, что рестор идет в 2-3 раза дольше бэкапа, удалять базу и сохранять бэкап видится мне некоторым маразмом.
(у некоторых людей бэкап ресторится прямо в процессе бэкапа, через пайпы, так что бэкап - это промежуточный процесс).

2. если же говорить про упаковку бэкапа и базы, то
бэкап меньше базы, потому что а) в нем нет индексов, б) он уже сжат (внезапно!).
Многие не в курсе, что при бэкапе тоже делается сжатие. Его можно выключить опцией -e. Мы тут недавно внутри проводили микро-эксперименты, и оказалось, что на 30гиговой базе TPCR бэкап обычный занимает 24 гиг, а с опцией -e - 34 гига, то есть, несжатый бэкап больше базы! Итого имеем - прирост в скорости бэкапа 7%, прирост объема бэкапа - 30%.
Если бэкап делается 10 часов, то с -e экономия, конечно, 48 минут. НО. См. выше про увеличение размера бэкапа.

Сжатие раром такого несжатого бэкапа (34 гиг) - 41 минута, размер архива - 6 гиг. Сжатие обычного бэкапа - 35 минут, архив 6 гиг. Опять же, разницы в размере нет, а по времени - есть. То есть, там выиграли 7%, а тут - потеряли те же где-то 7%.

Размер сжатой раром 30 гиг базы - 9 гиг, за 1 час. Но тут как-то и рестор шёл тоже час, комп явно тормозил, firefox пришлось убить.

Понятно, что сжатие зависит от данных внутри базы, архиватора и использования степени сжатия.

Короче, резюме: база 30 гиг, бэкап 24 гиг, разница 20%, значит, один и тот же объем или 10 бэкапов, или 8 баз. С учетом времени рестора из бэкапа - хранить базы выгоднее.
Если же сюда приплюсовать архивирование, то опять же, распаковывать бэкап а потом его ресторить - куда дольше готовой базы.
Архив базы 9 гиг против 6 гиг бэкапа - тоже понятно. И час упаковки базы против 35 минут упаковки бэкапа (кривой тест).
В общем, добавить нечего.

p.s. Собственно, идея "хранить бэкапы" перестает работать когда базы по 50-100 гиг и далее. Да и вообще, делать бэкап базы в 300 гиг а потом ресторить - это не для слабонервных. Старые технологии на нынешних объемах потихоньку перестают работать.

Гаджимурадов Рустамkdv> Размер сжатой раром 30 гиг базы - 9 гиг, за 1 час.
Больно много. Может, ты бэкап имел в виду, а не БД ?
не. Сжатие раром обычного бэкапа в 24 гиг заняло 6 гиг и длилось 36 минут.
Со сжатием раром исходной базы случился косяк - еще при ресторе ФБ3 сожрало почти всю память (16 гиг), и началось вываливание в виртуалку. Видать, что-то я такое перед этим делал, раньше такого не наблюдал.
Ну и, последующая архивация полученной базы тоже прошла как-то не быстро, RAR паковал базу со скоростью 9мб в минуту.

Так что, я могу предположить, что архивация базы и бэкапа должна быть такой же пропорциональной (примерно), как архивация сжатой и несжатой базы. Хотя, по конечному размеру архива это не так (9 против 6 и 6 гиг).

Повторять эту мутоту завтра я вообще не хочу. Моя основная мысль была в том, что
а) обычный бэкап уже сжат
б) тестовый рестор нужен
в) после тестового рестора бэкап надо выкидывать. Экономия места - это лабуда, экономия времени куда важнее.
Конечно, если бэкапы и ресторы идут минут по 15, на всё это можно наплевать, в том числе и на занимаемое бэкапами или базами место.

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

kdv,

9мб в секунду, конечно же.

Старый плюшевый мишка но и 7 штук за неделю + 12 за год. Горячая - результат тестового рестора, архив - бекапы. Базами жирновато будет, а понадобится раз в год по обещанию.
ага. у меня 1с настроена на 12 револьверных бэкапов. Бэкапы, понятное дело, совершаются 1-2 раза в день.
И вот, надо мне в Москву, значит залить свежий бэкап на ноут. И ...
Вижу я, что три последних бэкапа (а это тупо zip с копией базы) имеют размер, равный нулю.
Хорошо хоть, я эту фигню за полчаса устранил. Вот вам и бэкапы в архиве.

Гаджимурадов РустамНу как в анекдоте - не гиг, а мег
да ладно, тут на компе процесс идет, внук на шее сидит, жена готовит, а мне еще надо в полу-написанный коммент эти самые "мегабайты" воткнуть...

Гаджимурадов Рустама не бэкапы - рестора проверки логов нет, контроля нет.
так контролирует же 1С. Там как делается - ты типа закрываешь прогу, она тебе - сделать действия? Ты - да, делается бэкап, прога закрывается. Могли бы при старте проверять лог (что я и сделал потом, вручную), и кричать "ахтунг" - там же при старте масса вещей проверяется.
Самому автоматизировать тоже можно, но это ж надо скрипты писать :-)

Гаджимурадов РустамНу как в анекдоте - не гиг, а мег
уточню для потомков: корректировочная фраза
"9мб в секунду, конечно же. "
относилась к
"RAR паковал базу со скоростью 9мб в минуту."
а не к
"Размер сжатой раром 30 гиг базы - 9 гиг, за 1 час"