Создание бэкапа
Создание бэкапа
Приветствую всех!
Есть трехзвенка (Клиент->Сервер->БД).
На сервере есть опция создания бэкапа. Нужно создать бэкап на сервере (чтобы физически он находился на сервере) с учетом того, что БД находится на другой тачке.
У меня получается создать бэкап только на тачке БД.
Заранее спасибо!
Есть трехзвенка (Клиент->Сервер->БД).
На сервере есть опция создания бэкапа. Нужно создать бэкап на сервере (чтобы физически он находился на сервере) с учетом того, что БД находится на другой тачке.
У меня получается создать бэкап только на тачке БД.
Заранее спасибо!
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
эээ.. то есть документацию не осилил
gbak это клиентская софтина, ей только клиент IB/FB нужен для работы.
вообще организация вызывает сомнения. как я понял из писем, есть сервер А, на котором трехзвенка. И есть сервер Б с субд. И надо сделать бэкап с сервера Б на сервер А. Вопрос - ЗАЧЕМ?
С тем же успехом и может быть даже быстрее получится
1. сделать бэкап на сервере (через Services API),
2. зазиповать файл бэкапа,
3. кинуть файл бэкапа на любой компьютер с расшаренным каталогом в сети.
можно еще
1. запустить gbak на трехзвенке. бэкап как раз придет на трехзвенный сервер А с сервера Б. (gbak и Services API поддерживает, так что можно любые комбинации делать).
пытаться запустить gbak на сервере Б, и указывать для бэкапа шаренный на А каталог - тоже можно, но если это делается с сервера А, то... какой смысл с сервера А пытаться запустить процесс на сервере Б?
gbak это клиентская софтина, ей только клиент IB/FB нужен для работы.
вообще организация вызывает сомнения. как я понял из писем, есть сервер А, на котором трехзвенка. И есть сервер Б с субд. И надо сделать бэкап с сервера Б на сервер А. Вопрос - ЗАЧЕМ?
С тем же успехом и может быть даже быстрее получится
1. сделать бэкап на сервере (через Services API),
2. зазиповать файл бэкапа,
3. кинуть файл бэкапа на любой компьютер с расшаренным каталогом в сети.
можно еще
1. запустить gbak на трехзвенке. бэкап как раз придет на трехзвенный сервер А с сервера Б. (gbak и Services API поддерживает, так что можно любые комбинации делать).
пытаться запустить gbak на сервере Б, и указывать для бэкапа шаренный на А каталог - тоже можно, но если это делается с сервера А, то... какой смысл с сервера А пытаться запустить процесс на сервере Б?
Вижу, что задачу, которую поставил с самого начала я сформировал неконструктивно. Объясню подробнее.
Есть задача:
Нужно, чтобы бкп запускался и ложился на тачке, где стоит сервер (Application-server), хотя сама БД лежит на другой тачке.
Для чего это делается:
Чтобы рестор было удобнее делать. Не надо было расшаривать папку на БД и выбирать оттуда бкп, а проще выбирать его прям на той тачке, где стоит сервак, но ресторный бкп ляжет на тачку БД. И еще, своего рода безопасность от копирования бкпов из расшаренной папки.
Есть задача:
Нужно, чтобы бкп запускался и ложился на тачке, где стоит сервер (Application-server), хотя сама БД лежит на другой тачке.
Для чего это делается:
Чтобы рестор было удобнее делать. Не надо было расшаривать папку на БД и выбирать оттуда бкп, а проще выбирать его прям на той тачке, где стоит сервак, но ресторный бкп ляжет на тачку БД. И еще, своего рода безопасность от копирования бкпов из расшаренной папки.
сомнительное удобство. то есть бэкап перекачается с сервера БД на трехзвенку, а потом при ресторе - обратно. это надо хотя бы учесть.Чтобы рестор было удобнее делать.
ну... тогда да.И еще, своего рода безопасность от копирования бкпов из расшаренной папки.
насчет "расшаривания" не понял. Если делать b/r через services api, то бэкап и будет лежать на сервере БД, и ресториться там же. Никаких "шареных" папок.
С другой стороны, бэкапы принято куда-нибудь копировать, вовне - на СД, ДВД, ленту, другой физ. диск. По-моему делать это на апп-сервере неудобно. Потом, если надо базу заресторить, а сервер трехзвенки с бэкапами недоступен?
в общем, чего это я консультированием занимаюсь - ваше дело, как организовывать резервное копирование