Передо мной стоит задача перенести базу данных на другой сервер и минимизировать время простоя сервиса. База не маленькая - 12Гб, в ней есть хранимые процедуры и вьюшки. Самое простое - сделать бекап и развернуть на новом месте не подойдет из-за длительного времени простоя. При создании репликации я сталкиваюсь с предупреждением о том что view и процедуры нужно переносить руками. В результате я не совсем понимаю как быть? Можно ли сделать бекап рабочей базы, развернуть его на новом месте а уже потом настроить репликацию чтобы дореплицировалось только то что появилось за время переноса бекапа?
В идеале бы я хотел иметь 2 синхронные базы с которыми я бы мог работать одновременно, т.е. изменения в любой транслируются в другую базу. Помогите, пожалуйста, советом.

SERG1257Сделать полный бакап, а в момент Х сделать дифференциальный и накатить.
Спасибо за идею, я раньше так не пробовал делать.

Relic HunterMirroring, Log Shipping - не предлагать?
Насколько я знаю Mirroring держит базу приемник в состоянии недоступном для чтения. Чтобы она стала рабочей, нужно разорвать зеркалирование. Вероятно это тоже путь. Про Log Shipping ничего сказать не могу, т.к. ни разу не делал.

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

У меня simple модель.
По поводу дифф бекапа хотел спросить. Где система берет информацию с какого момента нужно делать дифф бекап? Правильно ли я понимаю что SQL запоминает когда был сделан последний полный бекап и относительно него делает дифф бекап?

Гавриленко Сергей АлексеевичЧтобы исчключить модификацию данных есть способ гораздо проще и надежней.
Как? Поделитесь пож

uaggster12 Тб может быть?
12Гб забекапить-скопировать-восстановить - это минут 10 отсилы.
Нет, у меня 12Гб, вообще сомнительная бравада - чтобы протолкнуть 12 Гб по сети нужна скорость 164 мегабит, в локальной сети возможно, но интернет - врядли. По факту у меня 10 минут только бекап делается.

SERG1257Надеюсь версия позволяет делать сжатый бакап?
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-compression-sql-server?view=sql-server-2017

Да, можно делать сжатый бекап. Я думаю реализовать идею с дифф бекапом, хочу понять, правильно ли я рассуждаю: после полного бекапа в базе хранится битовая карта экстентов, как написал alexeyvg, т.е. мои действия буквально:
1. снять полный бекап
2. мувнуть его на новую площадку
3. развернуть обычным способом
4. в нужный момент сделать дифф бекап (при этом в бекап сохранятся только изменения после полного бекапа)
5. мувнуть и накатить дифф бекап на новой площадке

Такой вопрос: а если на новой площадке поле разворота полного бекапа в базе будут изменения, как накатится дифф бекап? Или не накатится?