|
Как быстро клонировать SQL базу? | ☑ | ||
---|---|---|---|---|
0
tciban
19.11.19
✎
07:12
|
Коллеги! Есть такая проблема: довольно большая (1.5 террабайта) рабочая база, есть бакап (конечно), надо быстро развернуть 3 тесовых базы для 3-х разработчиков. Как это сделать наиболее быстро? Ну первую базу поднимаем из бакапа, а вот как быстро клонировать еще 2?
|
|||
1
shadow_sw
19.11.19
✎
07:14
|
хранилище и пусть сидят в одной базе
|
|||
2
shuhard
19.11.19
✎
07:16
|
(0) дык копия mdf + ldf, если сиквел MS
|
|||
3
Sergz66
19.11.19
✎
07:17
|
А точно всем разработчикам нужны полные копии рабочей базы? Может достаточно им пустые базы с нужной конфижкой сделать?
|
|||
4
dmpl
19.11.19
✎
07:26
|
(3) Ага, чтобы у разработчиков на тестовых данных работало, а на реальных - нет. Нужна не пустая база, а с реальными настройками и данными. Тут 2 варианта: копия рабочей базы, либо специально обученный человек делает тестовую базу по образу и подобию реальной, только с меньшим количеством данных (т.е. вводит тестовые примеры).
|
|||
5
Sergz66
19.11.19
✎
07:30
|
(4)Так о том и речь, что 4.5 Тбайта для разработки - это многовато...
|
|||
6
ДенисЧ
19.11.19
✎
07:31
|
(4) А если для этого обучить специально обученную программу? Зачем человек-то?
|
|||
7
Sergz66
19.11.19
✎
07:32
|
Как минимум после восстановления бэкапа выпилить из копии базы ненужные данные (например, сохраненные файлы, если они в базе лежат, может какие-то регистры, с которыми точно не будет работы)
|
|||
8
sitex
naïve
19.11.19
✎
07:35
|
(0) А что разработчикам нужны все данные в вашей базе ? Оставьте то что кому что нужно, остальное выпилить.
|
|||
9
tciban
19.11.19
✎
07:47
|
(1) Вот я не понял как это - в одной базе с помощью хранилища? Думал что много знаю про 1С, а тут прошу пояснить.
3 конфигуратора над одной базой не запустишь... Или ты имеешь ввиду над разными базами? Так нам нужны свежие данные. |
|||
10
tciban
19.11.19
✎
07:48
|
(3) Точно. И чтоб ты сам над пустой базой разработку вел (это проклятие такое :))
|
|||
11
tciban
19.11.19
✎
07:52
|
(8) Да. У нас нет какого-то настолько жесткого деления. И выпиливать скорее всего дольше чем копировать
Уважаемые коллеги! Давайте отодвинем в сторону дисскусию про потребность разработчика (каждого) в реальной базе. Все на эту тему меж собой мы давно обсудили. Кто мог - с весны не обновлялся :) Но теперь изменений в базе накопилось столько что точно надо. Давайте не будем спорить об этом - мы уже поспорили за вас. И прошу прощения, что лишили вас этого удовольствия :) Давайте лучше обсудим есть ли способ быстрого клонирования. Может средствами SQL как то? |
|||
12
Йохохо
19.11.19
✎
07:55
|
(11) а что вам мешает еще 2 базы поднять из бекапа?
|
|||
13
dk
19.11.19
✎
07:58
|
(2) +1
|
|||
14
dmpl
19.11.19
✎
08:00
|
(6) Чтобы правильно настроить эту программу.
|
|||
15
dmpl
19.11.19
✎
08:01
|
(8) Вопрос в том, что будет дешевле - выпилить, или каждому разработчику полную копию организовать... и не забыть, что ее надо будет обновлять периодически.
|
|||
16
tciban
19.11.19
✎
08:06
|
(12) Ничто не мешает. Просто думал если уж у насесть одна база, то может еще две получить можно еще быстрее?
|
|||
17
Йохохо
19.11.19
✎
08:16
|
(16) ну (2) может быть быстрее, а может не быть. А может вы РазработчикаНаПолутораТерабайтах полдня будете из копии уговаривать выйти служебками
|
|||
18
Irbis
19.11.19
✎
08:19
|
отатачить, скопировать три раза и прицепить. Если времени и места хватит.
|
|||
19
Sergz66
19.11.19
✎
08:21
|
(18) Не факт, что так быстрей будет, чем параллельно в три базы с одного бэкапа восстановить
|
|||
20
sitex
naïve
19.11.19
✎
08:25
|
(11) Тогда ответ (2). Быстрее чем так накатить средствами и скриптами SQL не получиться.
|
|||
21
tciban
19.11.19
✎
08:27
|
(18) бакап сильно меньше всей базы. Копировать его значительно быстрее.
бакап копируется полчаса (тестовые на отдельном сервере) восстановление из бакапа - 6 часов. Вопрос был собственно как уменьшить эти 6 часов. |
|||
22
Повелитель
19.11.19
✎
08:30
|
(0) (21) А в чем собственно проблема?
6 часов это разве время. Поставить на ночь, как раз у всех троих будет к утру по свежей базе. Можно одну из бэкапа поднять, а потом скопировать mdf + ldf елси MS SQL как выше писали, то всего займет 6 + 30 минут + 30 минут. |
|||
23
Irbis
19.11.19
✎
08:33
|
(21) Зато разворачивается бэкап значительно дольше.
|
|||
24
Fram
19.11.19
✎
08:36
|
(21) 6 часов? из дт что ли поднимаете?.. поднимать 6 часов 1.5тб из архива SQL это не нормально
|
|||
25
Повелитель
19.11.19
✎
08:38
|
(24) Вполне нормальное время. У меня база 100 Гб, поднимается из бэкапа 30 минут.
А тут в 15 раз больше база. |
|||
26
Повелитель
19.11.19
✎
08:38
|
(25) Даже просто скопировать по 1Гбитой сети 100Гб занимает около 15 минут.
|
|||
27
piter3
19.11.19
✎
08:40
|
(21) 6 часов,это персоналка что ли вместо сервера?
|
|||
28
seevkik
19.11.19
✎
08:40
|
а модель восстановления какая?
|
|||
29
Fram
19.11.19
✎
08:40
|
(25) ну может если копировать по сети 1.5тб, да - нормально. но если скопировать архив сначала локально на сервер, а потом поднять 6 часов - это долго
|
|||
30
Повелитель
19.11.19
✎
08:42
|
(27) Сейчас персоналка на SSD копирует быстрее, чем сервер с HDD последних моделей.
|
|||
31
tciban
19.11.19
✎
08:49
|
(21) Поднимаем из обычного SQL бакапа. Я не сисадмин, в настройках SQL не сильно то шарю, ускорить не знаю как.
|
|||
32
Sergz66
19.11.19
✎
08:52
|
(31)Так вы проанализируйте состав базы, какие таблицы самые большие. Наверняка найдете возможность грохнуть не сильно нужные для тестовой базы данные.
|
|||
33
ptiz
19.11.19
✎
08:54
|
(31) Без восстановления из бэкапа или копирования mdf - никак.
Ради интереса - все базы на одном сервере будут восстанавливаться? Там какая дисковая подсистема? |
|||
34
ptiz
19.11.19
✎
08:55
|
Нам вот пришлось raid-10 на raid-5 поменять, чтобы места больше стало на сервере под базы.
|
|||
35
Fram
19.11.19
✎
08:56
|
(34) со скоростью записи на raid-5 тоже мириться пришлось?
|
|||
36
sitex
naïve
19.11.19
✎
09:01
|
(31) Посмотрите на http://www.sql.ru, там есть тема как уменьшить размера физ. базы. Это только для копирования.
|
|||
37
piter3
19.11.19
✎
09:02
|
Может скажу глупость ибо ни разу не админ,а почему бы дифами не обновить тестовую.Как вариант
|
|||
38
Cyberhawk
19.11.19
✎
09:02
|
SQL snapshot
|
|||
39
mistеr
19.11.19
✎
09:02
|
Предлагаю быстрое решение. Всех разработчиков пустить в одну базу. Пусть между собой договариваются. И сказать: "Если что испортите - восстановление 6 часов!" Это подействует.
А правильное решение — не давать разработчикам рабочие базы. Пусть тестовые примеры делают, а то совсем обленились. Сделать выгрузку из рабочей базы основных справочников и настроек через КД не так сложно. |
|||
40
ДенисЧ
19.11.19
✎
09:03
|
Полтора терабайта скопировать быстрее, чем позволяет дисковая система - поможет только квантовый гуглёвский комп на 8096 кубитов...
|
|||
41
Cyberhawk
19.11.19
✎
09:03
|
+(38) SQL Mirroring
|
|||
42
ДенисЧ
19.11.19
✎
09:03
|
(39) Ты так и делаешь со своими разаработчиками? Из могилы пишешь?
|
|||
43
sitex
naïve
19.11.19
✎
09:04
|
(39) Ужас.!
|
|||
44
tciban
19.11.19
✎
09:07
|
(32) Что бы их грохнуть - надо время. И сначала надо восстановить полную базу. потом грохнуть.
(39) Ага. А если тебе поручили разработать отчет? Будешь ручками заводить документы. Ну ну... У тебя получится быстрый отчет, который будет всю полноту данных учитывать. Ага, ага. |
|||
45
mistеr
19.11.19
✎
09:08
|
(42) Обычно есть копия рабочей базы, но старая, обновляется раз в год примерно. Разворачивать копию на каждый чих смысла не вижу. Только если не удается воспроизвести ошибку.
|
|||
46
ptiz
19.11.19
✎
09:13
|
(35) SSD. Разницы не заметил никакой.
|
|||
47
Йохохо
19.11.19
✎
09:15
|
(46) умножение записи на рейд5 вроде х3 вместо х2, т.е. ресурс ссд / 1.5
|
|||
48
Sergz66
19.11.19
✎
09:34
|
(44)Ну так проанализировать один раз... На будущее... А дальше уже скулевыми скриптами можно будет обрезанные копии делать.
|
|||
49
kauksi
19.11.19
✎
09:47
|
разворачиваете одну копию, обрезаете по максимуму http://catalog.mista.ru/public/1154357/, отдаете обрезанную разработчикам
|
|||
50
dk
19.11.19
✎
09:48
|
(46) там разница будет при восстановлении работы в случае смерти одного или нескольких дисков, но для тестовой сойдет
|
|||
51
Lama12
19.11.19
✎
10:20
|
(0) Вопрос бюджета имеется?
|
|||
52
pechkin
19.11.19
✎
10:24
|
выпилить данные из рабочей базы будет сложнее и дольше чем просто скопировать эти 1.5т 3 раза
|
|||
53
pechkin
19.11.19
✎
10:25
|
ну и конечно тестовые примеры наше все. тогда рабочие данные нужны крайне редко
|
|||
54
Cyberhawk
19.11.19
✎
10:34
|
(53) Кто ж их генерить будет, один из ста)
|
|||
55
Lama12
19.11.19
✎
10:37
|
(53) Тестовые данные - супер. Только через 10 лет прогнул отдел аналитиков что б они отдельную базу вели с тестовым примером :-(, и то не уверен что приживется.
|
|||
56
Cyberhawk
19.11.19
✎
10:39
|
(55) Небось вручную колотить данные заставляешь, конечно не приживется
|
|||
57
pechkin
19.11.19
✎
10:40
|
(54) для каждой задачи свой пример.
калссическое тестирование бдд |
|||
58
pechkin
19.11.19
✎
10:41
|
его генерит разработчик.
все равно он его генерит для разработки, так почему бы не оформить как следует |
|||
59
Lama12
19.11.19
✎
10:42
|
(56) Пока вручную, дальше посмотрим. Может аварийные ситуации универсальным переносом будем из рабочей переносить.
(58) Разработчик сгенерит так, что у него все будет работать. :-) Проходили уже... |
|||
60
pechkin
19.11.19
✎
10:43
|
(59) просто у вас нет культуры доработки тестовых примеров.
нашли контр пример - написали новый тест |
|||
61
Cyberhawk
19.11.19
✎
10:44
|
(60) На чем тесты пишешь?
|
|||
62
pechkin
19.11.19
✎
10:45
|
xUnitFor1C
ванесса не зашла. да и вообще тестирование 1с через тестовый клиент- слишком медленно |
|||
63
Фрэнки
19.11.19
✎
10:47
|
Вообще, было бы любопытно послушать аргументацию, зачем нужна для постоянной разработки база в 1,5 ТБ.
Я как раз в отличие от ТС проклинал разработку в такой базе. Все действия в нее, связанные с применением структурного изменения к базе могли влететь внезапно на реструктуризацию и? Я курить давно бросил, если что Причем, не тестирование, а именно разработка. Сделал разработку. Нужен тест. Объем данных огромный. Кто в здравом уме пропустит этот тест на совесть просто разработчика и не выделить отдельный тестовый стенд с регламентом доступа к нему и с регламентом по признанию результатов? Ну если данные носят архиважный и критичный характер, иначе бы их никто и не хранил бы и уж тем более не тестировал. |
|||
64
Фрэнки
19.11.19
✎
10:50
|
Ну и наличие быстрообновленных свежих копий при огромном объеме источника - это сама по себе не рядовая задача.
Не думаю, что файловое или подобное файловому клонирование будет для этого адекватным решением. |
|||
65
Надо работать
19.11.19
✎
10:52
|
(0) поднимаешь одну из бекапа, сжимаешь средставими SQL? копируешь, подключаешь.
Экономия места и времени. Ну только на сжатие, но это один раз |
|||
66
Надо работать
19.11.19
✎
10:53
|
(63) а если у тебя реструктуризация пройдет за 20 минут, а на проде не пройдет за ночь? тоже не вариант
|
|||
67
ptiz
19.11.19
✎
10:59
|
(63) "могли влететь внезапно на реструктуризацию " - именно для этого и надо вести разработку на такой копии. Чтобы с рабочей не влететь.
|
|||
68
sitex
naïve
19.11.19
✎
11:06
|
(67) Интересно даже сколько она будет на 1,5 ТБ крутится и сколько памяти сожрет.
|
|||
69
Фрэнки
19.11.19
✎
11:12
|
Ага. Особенно, когда у тебя такая реструктуризация в процессе разработки над парой-тройкой параллельных заданий случится за один день несколько раз. А ты просто еще разрабатываешь. Тестить - это отдельно и это сделают все равно без тебя.
|
|||
70
Cyberhawk
19.11.19
✎
11:55
|
(66) Для этого существует препрод
|
|||
71
Cyberhawk
19.11.19
✎
11:56
|
(67) И тебе тоже (70)
|
|||
72
Cyberhawk
19.11.19
✎
11:59
|
Но даже если и нет препрода, то есть тестовый контур в виде центральной тестовой базы. База разработки совершенно точно не должна быть настолько большой, чтобы доставлять неудобства разработчику.
|
|||
73
dmpl
19.11.19
✎
12:11
|
(21) У вас где-то тормоза. 6 часов на 1,5 Тб - это средняя скорость 70 Мб/с. Нормальный дисковый массив может переварить ~500 Мб/с и выше. Нормальный SSD - 1 Гб/с и выше.
|
|||
74
pechkin
19.11.19
✎
12:12
|
(73) так еще и по сети наверно нужно качать.
ктож на продуктивах разворачивает тестовые базы для разработки |
|||
75
dmpl
19.11.19
✎
12:14
|
(49) Ага, а потом бьетесь 100500 часов над глюком из-за того, что обрезали лишнее... Обрезать должен тот, кто конфигурацию знает от и до. Сколько там его час стоит?
|
|||
76
assasu
19.11.19
✎
12:14
|
(0) видел организацию где спец скриптами убирали лишнее из рабочей базы. оставалось только нужное для разработчика на 5 тб
|
|||
77
ДенисЧ
19.11.19
✎
12:15
|
(76) "на 5 тб" ?
|
|||
78
Cyberhawk
19.11.19
✎
12:16
|
(75) 20% усилий дадут 80% результата, а большего и не требуется. Сломать при этом что-то - это надо постараться)
|
|||
79
pechkin
19.11.19
✎
12:16
|
для таких больших баз нужно отдельно разрабатывыать механизм создания тестовой базы
|
|||
80
assasu
19.11.19
✎
12:16
|
рабочая была 20 тб
|
|||
81
dmpl
19.11.19
✎
12:19
|
(74) БД, если туда не насовали JPEG'ов, жмется раз в 10. Так что пары Гбит/с хватит.
(78) В случае с ERP сломать - это запросто. Безболезненно можно убирать только вложенные файлы. |
|||
82
pechkin
19.11.19
✎
12:32
|
(81) а сколько времени будет жаться база на 1.5ТБ?
|
|||
83
Trance_1C
19.11.19
✎
13:00
|
Сжать файл журнала, скопировать базу в три каталога, подключить на сервере с разными именами, вроде все, зачем такую тему расплодили.
|
|||
84
ДенисЧ
19.11.19
✎
13:04
|
(83) 3 базы по 1.5 ТБ - это уже 5ТБ ))) И плюс время "скопировать базу"
|
|||
85
Trance_1C
19.11.19
✎
13:17
|
А размеры таблиц не смотрели, может у вас там история версий и регистр с проводками все место занимают.
чистятся одним запросом за 5 сек. Только не из 1С. |
|||
86
Trance_1C
19.11.19
✎
13:19
|
Подчистите самые жирные таблицы, все записи старше года в документах и регистрах, база похудеет заметно.
|
|||
87
Cyberhawk
19.11.19
✎
13:29
|
(81) Что-то ты придуриваешься
|
|||
88
dmpl
19.11.19
✎
17:32
|
(82) Зависит от настроек сжатия. Можно использовать что-то типа алгоритма, которым при гибернации жмут - там сотни МБ/с на ядро скорость даже на слабых ЦП. В принципе, MS SQL сам умеет жать бэкапы на лету довольно шустро.
|
|||
89
Креатив
19.11.19
✎
20:03
|
Я бы заархивировал mdf и ldf на другой носитель(не на тот, где файлы sql). Потом обратно в три каталога разархивировал. Это ежели не заморачиваться с оптимизацией базы.
|
|||
90
sergeyspb13
19.11.19
✎
23:16
|
http://qaru.site/questions/37050/how-can-i-clone-an-sql-server-database-on-the-same-server-in-sql-server-2008-express
можно из бэкапа сразу в новые базы развернуть... только и правда надо ли разработчикам столько |
|||
91
vde69
19.11.19
✎
23:27
|
1.5 тб средствами SQL на нормальном железе это 50...100 минут выгрузить и загрузить на соседнем сервере по сети (без копирования файла), штатно из энтерпрайса мышкой это не делается, а вот скриптом - легко, то есть если не переносить файл экономи по времени примерно минут 30....60 будет
|
|||
92
Bigbro
20.11.19
✎
07:00
|
(21) это странно. в нормальном режиме восстановление SQL бэкапа идет практически со скоростью копирования, а у вас разница в 12 раз.
что то с дисковой системой? |
|||
93
tciban
20.11.19
✎
07:53
|
(63) К вопросу зачем нужна большая база. Вот как раз для того, что бы оценить за какое время и как пройдет реструктуризация например. Мы должны понимать насколько долго будет происходить перенос наших изменений в рабочую базу. Работа круглосуточная, рабочую больше чем на час в день (в обед) не дают. Если на тестовой мы видим, что реструктуризация или иное изменение займет слишком долгое время - либо ищем другое решение, либо выбираем подходящий день когда отгрузка минимальна и нет иных мероприятий, договариваемся со всеми отделами. Например одно изменение пришлось откладывать 2 недели, сначала хотели в одну пятницу (там после 12 инвентаризация, отгрузки долго нет), но вдруг оказалось, что в этот день много работы у кассира, зарплата, заберем у нее базу - будут толпы людей злиться у кассы. Пришлось отложить до следующей пятницы.
В общем нужно иметь полноценный макет на котором можно заранее отработать все изменения и увидеть что будет с рабочей базой. Как в космической отрасли, когда они на земле оставляют точную копию того, что летит в космос, что бы посмотреть в живую всякое ;) |
|||
94
Индиго
20.11.19
✎
09:14
|
(93)Откуда такой монстр 1,5 Тб? Вы обрезку не делаете что ли из принципа?
|
|||
95
Sergz66
20.11.19
✎
09:17
|
(93)Вопрос-то в чём... нахрена несколько полных копий? Небольшие базы для разработки, полноценная копия - предпрод (ну может быть еще одна для тестирования пользователями), но разработка в базе в 1.5 Тб на железе, которое скорей всего хуже, чем на проде - это то еще развлечение...
|
|||
96
unregistered
20.11.19
✎
09:24
|
(94) > Вы обрезку не делаете что ли из принципа?
А зачем? Поиметь геморрой с выверкой остатков только ради того, чтобы копии для разрабов быстро делались? Боюсь пользователи не оценят. Это во-первых. А во-вторых, в зависимости от структуры и особенностей конфигурации свёртка может не давать достаточно большого уровня снижения объёмов базы. То есть геморрой получим, а уменьшение базы - нет. Типичный пример - почти все типовые конфигурации. В какой-нибудь бухне если из 10 лет ведения учёта свернуть данные за 5 лет, то сокращение объёма будет не на 50% (как может показаться), а в лучшем случае - 20-25%%, а реально ~15%. Но зато головняка с выверками остатков - вагон и маленькая тележка. |
|||
97
Vstur
20.11.19
✎
09:24
|
(93) логично. Сам затратные изменения обкатываю на полной копии базы, чтобы оценить временные интервалы. 365/7/24
|
|||
98
Vstur
20.11.19
✎
09:25
|
(96) +100500
|
|||
99
tciban
20.11.19
✎
09:32
|
(94) В частности главбух хочет иметь всю(!) историю. И не моя работа ее переубеждать...
(96) Кроме того свертак базы не даст экономии места потому, что (внезапно) надо будет оставить копию базы до свертки. Разработка на урезанной базе. Вот пример - сделал некоторую обработку, почти месяц назад, пару дней назад пользователи наткнулись на особенности в одном документе, которые я не учел. Поскольку база разработки у меня свежая, я спокойно сейчас переделываю обработку используя этот пример. А если бы у меня его не было, то что бы я делал? |
|||
100
Фрэнки
20.11.19
✎
09:34
|
(93) Никто не спорит, что Тестовая база, равная по всем показателям текущей, рабочей должна быть.
Оспаривается мнение, что полных копий нужно обязательно много и каждый разработчик просто обязан заниматься разработкой исключительно в полной копии. Между прочим, есть ситуации, когда, даже при огромном желании разработчика получить полную копию боевой базы в свое владение и под полный контроль, ему категорически в этом отказывают. Причем, если базы действительно огромные, то отказ обосновывается не только и не столько вопросами коммерческой и какой-то еще тайной, но и техническими возможностями серверов заказчика, например. |
|||
101
Фрэнки
20.11.19
✎
09:45
|
Я просто не хочу указывать на конкретные имена работодателей и периоды работы у них, но это реальные ограничения, которые известны мне из практики работы на Заказчика, когда сводная команда 1с-специалистов у этого Заказчика насчитывала порядка 20+ программистов только, не считая всех остальных консультантов и прочих. И вся эта толпа спецов работала фактически в удаленных режимах, т.е. только для разработчиков была установлено две фермы со средним числом активных сеансов порядка 10 штук на каждой - т.е. около 20 сеансов конфигуратора (не пользователей) я видел через оснастку администрирования 1С сервера и понятно, что каждому конфигуратору своя базочка.
|
|||
102
tciban
20.11.19
✎
09:47
|
(100) (101) Я не оспариваю того, что случаи бывают разные, но я и мои коллеги находятся в конкретной ситуации, которую и обсуждаем.
|
|||
103
mistеr
20.11.19
✎
10:50
|
(99) >А если бы у меня его не было, то что бы я делал?
Подключился бы к боевой, посмотрел его особенности и создал бы такой же ручками. Или выгрузил в XML. Разработчики типовых, к примеру, вообще не имеют доступа к боевым базам и ничего, не жалуются. |
|||
104
Bigbro
20.11.19
✎
11:14
|
(103) жалуются потом пользователи этих типовых. и программисты на местах, когда признанные ошибки существуют годами без исправления.
|
|||
105
tciban
20.11.19
✎
11:33
|
(103) Я не один такой, нас тут 4-ро. И у каждого может возникнуть потребность в отладке возникшей ситуации. При том у кого то - срочная, без этого типа работа встала, а у кого-то надо просто исправить, но не немедленно. Собственно так мы работаем по текущему дню, когда тестовую не обновить.
|
|||
106
tciban
20.11.19
✎
11:35
|
(104) Во-во! Недано писали кто т она хабре как в 1С работал, отмечал что они там от земли оторвались давно. Хорошо работать в уютненькой тестовой базке с идеальными данными. А вот пользователи такого могут наворотить...
|
|||
107
unregistered
20.11.19
✎
11:54
|
По сути вопроса.
Восстанавливать из бекапа одну базу. Вторую и третью - тупо копированием файлов первой восстановленной базы. Можно нарисовать скрипты и хоть бы даже по расписанию их запускать, чтобы каждое утро иметь три актуальных копии базы. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |