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 час"

Belotsky Sergeно это долго, а быстрее можно?
Вариантов 2

1. gbak -b -g, gbak -c
2. gfix -v

проверка БД это либо 1, либо 2.

Arioch34 ГиБ = 34816 МиБ на обычной линейной скорости винчестера это 348 секунд, чуть меньше 6 минут
Бэкап делали на тот же диск, с которого базу читали? и уперлись в thrashing?
я вообще не понял, про что это. Скопировать 34 гига на скорости 100мб сек с одного физ диска на другой - да, это 6 минут.
И что?
Бэкапы я всегда делаю на другой физический диск, мне зря терять время на одном диске некогда.
А архивация обычно (зависит от архиватора) делается на тот же диск.
Бэкап - это не копирование. Архивация - это не копирование.

Проц FX8350, диски hdd sata2, копирование у всех не меньше 100мб сек.
Rar при скорости чтения файла в 9мб в секунду грузит 4 ядра на 80% (в итоге получается где-то 40% загрузки всего процессора),
сжатие - среднее.
Ariochне оказалось ли бы их раздельное сжатие лучше, чем когда всё в перемешку....
архиватор про типы страниц ФБ ничего не знает, и вряд ли будет знать.

Ariochи начал их разбивать на 4 потока, которые сжимались независимо.
у нас были эксперименты с параллельным сжатием на линуксе, в результате иногда архивы получаются битыми. Отказались.

Ariochи то, что мне с трудом верится, что RAR не мог сжать с одного диска на другой с такой же ровно скоростью
я специально отметил, что rar пакует на этот же диск.
А предположение о том, что архиватор будет сжимать со скоростью копирования - это бред, ты уж меня извини.
Ariochучитывая разницу в скорости HDD и современных CPU/RAM, плюс настраиваемую степень сжатия архиваторов, плюс экспоненциальную рост "стоимости" усиления сжатия - можно считать, что это одно и то же
нет, не одно и то же. При копировании ресурсы процессора практически не тратятся.
А при бэкапе идет вычитка данных со страниц, формирование версий, и их формирование для записи в бэкап. Это процессорная работа.
При архивации процессор используется еще сильнее. Так что не надо загибать про "одно и то же".

Вместо вот этих голословных предположений возьми любой файл размером около 10 гиг, и сравни
- копирование файла с диска на диск
- архивирование этого файла.

Если у тебя получится одно и то же - ну, я тебя поздравляю, у тебя суперкомпьютер вместо процессора.

AriochНастрой, чтобы он сжимал примерно с той скоростью, с которой диски позволяют читать и писать.
настраивается только сжатие и многопоточность.
При минимальном сжатии предполагаемое время архивации 30 гиг с одного диска на диск - 11 минут.
Я уже вижу, что чтение идет ~40мб сек, а запись - ~12мб сек.
То есть, до 100мб чтения как раком до Москвы.
проц загружен на 1 ядро из 8 (13%), почему так, при явно установленной "многопоточности" - х.з.

Гаджимурадов РустамЭто что за диски такие?
это архиватор так работает. Использует одно ядро, и в него упирается.

Короче, по 30 гиг базе итог:

- просто копирование с диска на диск - чтение и запись 125мб сек, 4 минуты (это к вопросу о дисках. "Принимающий" диск быстрее, чем "источник").

rar, многопоточность включена (но используется одно ядро, потому что старт в интерактивном режиме),
низкий приоритет выключен, база на одном диске, архив идет на другой диск:

- сжатие "скоростное", результат - 11 гиг, 14 минут. По чтению это 35мб в секунду. Вопросы про "сжатие со скоростью диска" есть?
(если бы читалось и паковалось в 4 ядра, было бы чтение 140 мб, но ... rar не хочет так)

- сжатие "без сжатия", результат - 30 гиг, 4 минуты (как и копирование).

Я напомню, что база 30 гиг, а памяти у меня 16 гиг (специально не 32), то есть, база в файловый кэш ОС не влезает.
Поэтому, если кто-то у себя хочет потестировать, учитывайте этот момент. В случае "база меньше RAM" результаты будут быстрее.

p.s. про странности с многопоточностью rar - если в проводнике сказать "упакуй в rar", то в таком режиме при паковке используется 2 ядра, то есть проц загружен на 25%. Но скорость чтения я тут проверить не могу, потому что в этом режиме рар пишет на этот же диск, получается скорость чтения вообще 15мб сек.

Ariochодин диск, механический
половину времени занимает thrashing головки между дорожками, половину - реальное чтение и запись
нихрена ты не угадал. Пока что всё мимо, совершенно.

Короче, я вам не тестовая машина, хотите дальше - тестируйте сами. Свои данные я привел, мой комп это мой комп.
Так что, предлагаю вам самостоятельно опровергнуть ваши собственные догадки, практическим способом - про "скорость архивации со скоростью записи", "trashing", "один диск" и прочее.

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

Mironico,
обнови ФБ 2.5

Mironico,

чтобы прямо уж совсем точно:
Firebird 2.5.4 Sub-release
From this sub-release forward, it is now possible to perform table and index validation whilst the database is on-line.