Коллеги! Есть такая проблема: довольно большая (1.5 террабайта) рабочая база, есть бакап (конечно), надо быстро развернуть 3 тесовых базы для 3-х разработчиков. Как это сделать наиболее быстро? Ну первую базу поднимаем из бакапа, а вот как быстро клонировать еще 2?

хранилище и пусть сидят в одной базе

(0) дык копия mdf + ldf, если сиквел MS

А точно всем разработчикам нужны полные копии рабочей базы? Может достаточно им пустые базы с нужной конфижкой сделать?

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

(4)Так о том и речь, что 4.5 Тбайта для разработки - это многовато...

(4) А если для этого обучить специально обученную программу? Зачем человек-то?

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

(0) А что разработчикам нужны все данные в вашей базе ? Оставьте то что кому что нужно, остальное выпилить.

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

(3) Точно. И чтоб ты сам над пустой базой разработку вел (это проклятие такое :))

(8) Да. У нас нет какого-то настолько жесткого деления. И выпиливать скорее всего дольше чем копировать
Уважаемые коллеги! Давайте отодвинем в сторону дисскусию про потребность разработчика (каждого) в реальной базе. Все на эту тему меж собой мы давно обсудили. Кто мог - с весны не обновлялся :) Но теперь изменений в базе накопилось столько что точно надо. Давайте не будем спорить об этом - мы уже поспорили за вас. И прошу прощения, что лишили вас этого удовольствия :)

Давайте лучше обсудим есть ли способ быстрого клонирования. Может средствами SQL как то?

(11) а что вам мешает еще 2 базы поднять из бекапа?

(2) +1

(6) Чтобы правильно настроить эту программу.

(8) Вопрос в том, что будет дешевле - выпилить, или каждому разработчику полную копию организовать... и не забыть, что ее надо будет обновлять периодически.

(12) Ничто не мешает. Просто думал если уж у насесть одна база, то может еще две получить можно еще быстрее?

(16) ну (2) может быть быстрее, а может не быть. А может вы РазработчикаНаПолутораТерабайтах полдня будете из копии уговаривать выйти служебками

отатачить, скопировать три раза и прицепить. Если времени и места хватит.

(18) Не факт, что так быстрей будет, чем параллельно в три базы с одного бэкапа восстановить

(11) Тогда ответ (2). Быстрее чем так накатить средствами и скриптами SQL не получиться.

(18) бакап сильно меньше всей базы. Копировать его значительно быстрее.
бакап копируется полчаса (тестовые на отдельном сервере) восстановление из бакапа - 6 часов. Вопрос был собственно как уменьшить эти 6 часов.

(0) (21) А в чем собственно проблема?
6 часов это разве время. Поставить на ночь, как раз у всех троих будет к утру по свежей базе.

Можно одну из бэкапа поднять, а потом скопировать mdf + ldf елси MS SQL как выше писали, то всего займет 6 + 30 минут + 30 минут.

(21) Зато разворачивается бэкап значительно дольше.

(21) 6 часов? из дт что ли поднимаете?.. поднимать 6 часов 1.5тб из архива SQL это не нормально

(24) Вполне нормальное время. У меня база 100 Гб, поднимается из бэкапа 30 минут.
А тут в 15 раз больше база.

(25) Даже просто скопировать по 1Гбитой сети 100Гб занимает около 15 минут.

(21) 6 часов,это персоналка что ли вместо сервера?

а модель восстановления какая?

(25) ну может если копировать по сети 1.5тб, да - нормально. но если скопировать архив сначала локально на сервер, а потом поднять 6 часов - это долго

(27) Сейчас персоналка на SSD копирует быстрее, чем сервер с HDD последних моделей.

(21) Поднимаем из обычного SQL бакапа. Я не сисадмин, в настройках SQL не сильно то шарю, ускорить не знаю как.

(31)Так вы проанализируйте состав базы, какие таблицы самые большие. Наверняка найдете возможность грохнуть не сильно нужные для тестовой базы данные.

(31) Без восстановления из бэкапа или копирования mdf - никак.
Ради интереса - все базы на одном сервере будут восстанавливаться? Там какая дисковая подсистема?

Нам вот пришлось raid-10 на raid-5 поменять, чтобы места больше стало на сервере под базы.

(34) со скоростью записи на raid-5 тоже мириться пришлось?

(31) Посмотрите на http://www.sql.ru, там есть тема как уменьшить размера физ. базы. Это только для копирования.

Может скажу глупость ибо ни разу не админ,а почему бы дифами не обновить тестовую.Как вариант

SQL snapshot

Предлагаю быстрое решение. Всех разработчиков пустить в одну базу. Пусть между собой договариваются. И сказать: "Если что испортите - восстановление 6 часов!" Это подействует.

А правильное решение — не давать разработчикам рабочие базы. Пусть тестовые примеры делают, а то совсем обленились. Сделать выгрузку из рабочей базы основных справочников и настроек через КД не так сложно.

Полтора терабайта скопировать быстрее, чем позволяет дисковая система - поможет только квантовый гуглёвский комп на 8096 кубитов...

+(38) SQL Mirroring

(39) Ты так и делаешь со своими разаработчиками? Из могилы пишешь?

(39) Ужас.!

(32) Что бы их грохнуть - надо время. И сначала надо восстановить полную базу. потом грохнуть.

(39) Ага. А если тебе поручили разработать отчет? Будешь ручками заводить документы. Ну ну... У тебя получится быстрый отчет, который будет всю полноту данных учитывать. Ага, ага.

(42) Обычно есть копия рабочей базы, но старая, обновляется раз в год примерно. Разворачивать копию на каждый чих смысла не вижу. Только если не удается воспроизвести ошибку.

(35) SSD. Разницы не заметил никакой.

(46) умножение записи на рейд5 вроде х3 вместо х2, т.е. ресурс ссд / 1.5

(44)Ну так проанализировать один раз... На будущее... А дальше уже скулевыми скриптами можно будет обрезанные копии делать.

разворачиваете одну копию, обрезаете по максимуму http://catalog.mista.ru/public/1154357/, отдаете обрезанную разработчикам

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

(0) Вопрос бюджета имеется?

выпилить данные из рабочей базы будет сложнее и дольше чем просто скопировать эти 1.5т 3 раза

ну и конечно тестовые примеры наше все. тогда рабочие данные нужны крайне редко

(53) Кто ж их генерить будет, один из ста)

(53) Тестовые данные - супер. Только через 10 лет прогнул отдел аналитиков что б они отдельную базу вели с тестовым примером :-(, и то не уверен что приживется.

(55) Небось вручную колотить данные заставляешь, конечно не приживется

(54) для каждой задачи свой пример.
калссическое тестирование бдд

его генерит разработчик.
все равно он его генерит для разработки, так почему бы не оформить как следует

(56) Пока вручную, дальше посмотрим. Может аварийные ситуации универсальным переносом будем из рабочей переносить.
(58) Разработчик сгенерит так, что у него все будет работать. :-) Проходили уже...

(59) просто у вас нет культуры доработки тестовых примеров.
нашли контр пример - написали новый тест

(60) На чем тесты пишешь?

xUnitFor1C
ванесса не зашла. да и вообще тестирование 1с через тестовый клиент- слишком медленно

Вообще, было бы любопытно послушать аргументацию, зачем нужна для постоянной разработки база в 1,5 ТБ.

Я как раз в отличие от ТС проклинал разработку в такой базе. Все действия в нее, связанные с применением структурного изменения к базе могли влететь внезапно на реструктуризацию и? Я курить давно бросил, если что

Причем, не тестирование, а именно разработка.

Сделал разработку. Нужен тест. Объем данных огромный. Кто в здравом уме пропустит этот тест на совесть просто разработчика и не выделить отдельный тестовый стенд с регламентом доступа к нему и с регламентом по признанию результатов? Ну если данные носят архиважный и критичный характер, иначе бы их никто и не хранил бы и уж тем более не тестировал.

Ну и наличие быстрообновленных свежих копий при огромном объеме источника - это сама по себе не рядовая задача.
Не думаю, что файловое или подобное файловому клонирование будет для этого адекватным решением.

(0) поднимаешь одну из бекапа, сжимаешь средставими SQL? копируешь, подключаешь.

Экономия места и времени. Ну только на сжатие, но это один раз

(63) а если у тебя реструктуризация пройдет за 20 минут, а на проде не пройдет за ночь? тоже не вариант

(63) "могли влететь внезапно на реструктуризацию " - именно для этого и надо вести разработку на такой копии. Чтобы с рабочей не влететь.

(67) Интересно даже сколько она будет на 1,5 ТБ крутится  и сколько памяти сожрет.

Ага. Особенно, когда у тебя такая реструктуризация в процессе разработки над парой-тройкой параллельных заданий случится за один день несколько раз. А ты просто еще разрабатываешь. Тестить - это отдельно и это сделают все равно без тебя.

(66) Для этого существует препрод

(67) И тебе тоже (70)

Но даже если и нет препрода, то есть тестовый контур в виде центральной тестовой базы. База разработки совершенно точно не должна быть настолько большой, чтобы доставлять неудобства разработчику.

(21) У вас где-то тормоза. 6 часов на 1,5 Тб - это средняя скорость 70 Мб/с. Нормальный дисковый массив может переварить ~500 Мб/с и выше. Нормальный SSD - 1 Гб/с и выше.

(73) так еще и по сети наверно нужно качать.
ктож на продуктивах разворачивает тестовые базы для разработки

(49) Ага, а потом бьетесь 100500 часов над глюком из-за того, что обрезали лишнее... Обрезать должен тот, кто конфигурацию знает от и до. Сколько там его час стоит?

(0) видел организацию где спец скриптами убирали лишнее из рабочей базы. оставалось только нужное для разработчика на 5 тб

(76) "на 5 тб" ?

(75) 20% усилий дадут 80% результата, а большего и не требуется. Сломать при этом что-то - это надо постараться)

для таких больших баз нужно отдельно разрабатывыать механизм создания тестовой базы

рабочая была 20 тб

(74) БД, если туда не насовали JPEG'ов, жмется раз в 10. Так что пары Гбит/с хватит.

(78) В случае с ERP сломать - это запросто. Безболезненно можно убирать только вложенные файлы.

(81) а сколько времени будет жаться база на 1.5ТБ?

Сжать файл журнала, скопировать базу в три каталога, подключить на сервере с разными именами, вроде все, зачем такую тему расплодили.

(83) 3 базы по 1.5 ТБ - это уже 5ТБ ))) И плюс время "скопировать базу"

А размеры таблиц не смотрели, может у вас там история версий и регистр с проводками все место занимают.
чистятся одним запросом за 5 сек. Только не из 1С.

Подчистите самые жирные таблицы, все записи старше года в документах и регистрах, база похудеет заметно.

(81) Что-то ты придуриваешься

(82) Зависит от настроек сжатия. Можно использовать что-то типа алгоритма, которым при гибернации жмут - там сотни МБ/с на ядро скорость даже на слабых ЦП. В принципе, MS SQL сам умеет жать бэкапы на лету довольно шустро.

Я бы заархивировал mdf и ldf на другой носитель(не на тот, где файлы sql). Потом обратно в три каталога разархивировал. Это ежели не заморачиваться с оптимизацией базы.

http://qaru.site/questions/37050/how-can-i-clone-an-sql-server-database-on-the-same-server-in-sql-server-2008-express
можно из бэкапа сразу в новые базы развернуть... только и правда надо ли разработчикам столько

1.5 тб средствами SQL на нормальном железе это 50...100 минут выгрузить и загрузить на соседнем сервере по сети (без копирования файла), штатно из энтерпрайса мышкой это не делается, а вот скриптом - легко, то есть если не переносить файл экономи по времени примерно минут 30....60 будет

(21) это странно. в нормальном режиме восстановление SQL бэкапа идет практически со скоростью копирования, а у вас разница в 12 раз.
что то с дисковой системой?

(63) К вопросу зачем нужна большая база. Вот как раз для того, что бы оценить за какое время и как пройдет реструктуризация например. Мы должны понимать насколько долго будет происходить перенос наших изменений в рабочую базу. Работа круглосуточная, рабочую больше чем на час в день (в обед) не дают. Если на тестовой мы видим, что реструктуризация или иное изменение займет слишком долгое время - либо ищем другое решение, либо выбираем подходящий день когда отгрузка минимальна и нет иных мероприятий, договариваемся со всеми отделами. Например одно изменение пришлось откладывать 2 недели, сначала хотели в одну пятницу (там после 12 инвентаризация, отгрузки долго нет), но вдруг оказалось, что в этот день много работы у кассира, зарплата, заберем у нее базу - будут толпы людей злиться у кассы. Пришлось отложить до следующей пятницы.

В общем нужно иметь полноценный макет на котором можно заранее отработать все изменения и увидеть что будет с рабочей базой.
Как в космической отрасли, когда они на земле оставляют точную копию того, что летит в космос, что бы посмотреть в живую всякое ;)

(93)Откуда такой монстр 1,5 Тб?   Вы обрезку не делаете что ли из принципа?

(93)Вопрос-то в чём... нахрена несколько полных копий? Небольшие базы для разработки, полноценная копия - предпрод (ну может быть еще одна для тестирования пользователями), но разработка в базе в 1.5 Тб на железе, которое скорей всего хуже, чем на проде - это то еще развлечение...

(94) > Вы обрезку не делаете что ли из принципа?

А зачем?
Поиметь геморрой с выверкой остатков только ради того, чтобы копии для разрабов быстро делались? Боюсь пользователи не оценят. Это во-первых.

А во-вторых, в зависимости от структуры и особенностей конфигурации свёртка может не давать достаточно большого уровня снижения объёмов базы. То есть геморрой получим, а уменьшение базы - нет. Типичный пример - почти все типовые конфигурации. В какой-нибудь бухне если из 10 лет ведения учёта свернуть данные за 5 лет, то сокращение объёма будет не на 50% (как может показаться), а в лучшем случае - 20-25%%, а реально ~15%. Но зато головняка с выверками остатков - вагон и маленькая тележка.

(93) логично. Сам затратные изменения обкатываю на полной копии базы, чтобы оценить временные интервалы. 365/7/24

(96) +100500

(94) В частности главбух хочет иметь всю(!) историю. И не моя работа ее переубеждать...

(96) Кроме того свертак базы не даст экономии места потому, что (внезапно) надо будет оставить копию базы до свертки.

Разработка на урезанной базе. Вот пример - сделал некоторую обработку, почти месяц назад, пару дней назад пользователи наткнулись на особенности в одном документе, которые я не учел. Поскольку база разработки у меня свежая, я спокойно сейчас переделываю обработку используя этот пример. А если бы у меня его не было, то что бы я делал?

(93) Никто не спорит, что Тестовая база, равная по всем показателям текущей, рабочей должна быть.

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

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

Я просто не хочу указывать на конкретные имена работодателей и периоды работы у них, но это реальные ограничения, которые известны мне из практики работы на Заказчика, когда сводная команда 1с-специалистов у этого Заказчика насчитывала порядка 20+ программистов только, не считая всех остальных консультантов и прочих. И вся эта толпа спецов работала фактически в удаленных режимах, т.е. только для разработчиков была установлено две фермы со средним числом активных сеансов порядка 10 штук на каждой - т.е. около 20 сеансов конфигуратора (не пользователей) я видел через оснастку администрирования 1С сервера и понятно, что каждому конфигуратору своя базочка.

(100) (101) Я не оспариваю того, что случаи бывают разные, но я и мои коллеги находятся в конкретной ситуации, которую и обсуждаем.

(99) >А если бы у меня его не было, то что бы я делал?

Подключился бы к боевой, посмотрел его особенности и создал бы такой же ручками. Или выгрузил в XML.

Разработчики типовых, к примеру, вообще не имеют доступа к боевым базам и ничего, не жалуются.

(103) жалуются потом пользователи этих типовых. и программисты на местах, когда признанные ошибки существуют годами без исправления.

(103) Я не один такой, нас тут 4-ро. И у каждого может возникнуть потребность в отладке возникшей ситуации. При том у кого то - срочная, без этого типа работа встала, а у кого-то надо просто исправить, но не немедленно. Собственно так мы работаем по текущему дню, когда тестовую не обновить.

(104) Во-во! Недано писали кто т она хабре как в 1С работал, отмечал что они там от земли оторвались давно. Хорошо работать в уютненькой тестовой базке с идеальными данными. А вот пользователи такого могут наворотить...

По сути вопроса.
Восстанавливать из бекапа одну базу.
Вторую и третью - тупо копированием файлов первой восстановленной базы.
Можно нарисовать скрипты и хоть бы даже по расписанию их запускать, чтобы каждое утро иметь три актуальных копии базы.