Правильная организация Backup/Restore с удалённого клиента.

[MEV]

К сожалению на форуме так и не нашёл алгоритма для организации backup/restore c удалённого клиента. Предполагается что к серверу клиенты имеют доступ только по TCP. (никакой шары и пр.)

Необходимо реализовать корректный механизм backup/restore с клиента.
Для работы с FireBird используются компоненты FIBPlus.
Т.к. делать restore в рабочую базу КАТЕГОРИЧЕСКИ не рекомендуется, то после backup выполняется restore во временный fdb-шник с другим именем. Потом основную базу можно dropнуть, но временный fdb, как я понимаю, переименовать средствами firebirda нельзя (или всё таки можно?).
Т.к. доступа к папке с файлами БД у клиента нет, то и его средствами переименовать временный fdb-шник не получится.

В общем, родился простенький алгоритм для решения этой проблемы.
1. Создаётся дополнительный fdb (dbname.fdb), в котором хранится имя основного fdb.
2. Для соединения с основным fdb, клиент сначала коннектится к dbname.fdb, получает имя основного fdb, после чего к нему и коннектится.
3. Алгоритм backup/restore выглядит следующим образом :
3.1 Делаем backup и restorим его в dd_mm_yy.fdb (т.е. новый fdb имя которого получаем по определённому алгоритму)
3.2 Переписываем в dbname.fdb имя основной fdb на dd_mm_yy.fdb.
3.3 Делаем drop старого fdb.

Вопрос в том, не изобретаю ли я велосипед?

[Georgi-47]

Автоматически удалять рабочую базу и работать с только что восстановленной тоже не самая лучшая идея. По крайней мере надо тогда разбирать лог бэкапа-восстановления, чтобы "быть уверенным", что восстановление и бэкап перед ним прошли нормально. Но все равно, я бы не стал автоматом удалять рабочую базу. А вдруг в замечательной проге бэкапа-восстановления ошибка вкралась, и через пару лет она проявится, убьет базу, а новую не восстановит?
И еще, на мой взгляд, чаще всего нет необходимости ежедневно таким образом "чистить" БД, вполне достаточно делать это раз в месяц, например, даже для довольно интенсивного режима вставок-удалений.

[MEV]

[kdv]

[DS]

Оч содержательный вопросительный знак.

Т.к. делать restore в рабочую базу КАТЕГОРИЧЕСКИ не рекомендуется...

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