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

Цель эксперемента выяснить можно ли файлы mdf и ldf снятые с рабочей базы в рабочем режиме с помощью VSS (утилита hobocopy). Стать полноценной заменой обычной резервной копии. Сейчас сделал такую копию, прогнал её на DBCC CHECKDB, ошибок нет, документы на месте. Пока всё штатно.

P.S. Почему не подходит выгрузка: База удалённо переносится с помощью rsync на удалённый ящик. Выгрузка bak ни сжатая ни не сжатая не очень подходят для rsync, так как файл одной и той же базы измененной в течение дня перекачивается чуть ли не весь (не весь конечно, но далеко от того как лихо перекачивается файловая база). Из чего делаю вывод что одни и те же данные в выгружаются в bak файле в разные места, из-за чего нет возможности выявить изменённые данные путём сравнивания контрольных сумм блоков, находящихся на одном и том же смещении относительно начала файла. Есть надежда, что mdf не сильно меняется с течением времени и его возможно синхронизировать.

Часть данных конечно я могу не получить, так как какая-то часть транзаций ещё не прошла, это понятно. Интересует целостность такой базы, если слепок mdf и ldf файлов производится одновременно.

(0) надо же так усложнить себе жизнь. делай дифы в течении дня. фул раз в сутки.

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

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

для этого придумали разностные бэкапы

(1) Схема Comp1------------INTERNET---------Comp2
Понимаете? Иногда передача всей базы через не очень широкий канал не очень рациональная идея. (а передавать нужно)
Да диффы я передам. Но раз в сутки придется мотылять в моём случае 25 гб (сжатый bak). Это не торт для канала, которым я располагаю.

(2) вот цифры: mdf - 55 gb, несжатый bak 50 gb, сжатый 25.
Пусть он будет с пустотами. Мне важно, чтобы одинаковые блоки данных не ездили туда-сюда по файлу.

(3) ясно что тупость. но что может случиться и почему. вот в чем вопрос.

(4) тоже самое. что (1)

Схема с разностными копиями опробована на отлично(http://catalog.mista.ru/public/700320/). Хочется сэкономить на перекачке bak.

(0) Можно. Перед ребутом сервера в логофф скрипте с RAM-памяти копируются файлы на хард. Потом переносятся обратно и включается сервер.

Только лучше размер кластера ставить 64КБ - немного потеряете месте, но скорость операции возрастет в разы. Файл mdf 70Гб копируется со скоростью примерном Гбайт/сек (с РАM диска на SSD).

(5).1 понимаем. и дифф бэкап будет не равен всему бэкапу.
(5).2 у меня средний коэффициент сжатия бэкапа - более пяти, а не два. Кстати, зиповать сжатый бэкап не надо.
(5).3 если одна транзакция скуль сервера разбивается на несколько транзакций ntfs, то можно получить неконсистентные данные, например итоги отличающиеся от суммы всех движений. Или проведенный документ с частью движений. Или шапку документа одной версии, а таб часть другой. Однако, работает ли так скуль сервер (разбивает ли транзакции) - мне неизвестно. Если хочется рисковать - пожалуйста. С разностными бэкапами, сделанными в том же скрипте, что и rsync, проблем будет явно меньше, да и для истории лучше, когда есть последовательность бэкапов, а не один бэкап, в котором уже содержаться убитые данные (потому что вспомнили слишком поздно).
Лично у меня хранится история на начало каждого месяца, последний год - еще дополнительно начало каждой недели, и последний месяц - начало каждого дня.

(7) я так понимаю, автор онлайн хочет, без остановки сервера.

(9) зип сжатого бекапа давал еще процентов 10-20 насколько я помню

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

хреновая схема в 1. не понятно зачем так извращать обычную простую операцию.

(12)  У автора спец прога для резервного копирования системы и он говорит. Если знать, что она работает по принципу разностных копий, то вы бы поняли, что хочет сказать ТС: бэкапы sql каждый раз имеют разный бинарный вид и прога потому бэкапит каждый раз все по новой.

(9)
3 - вот... это вполне техническое обоснование.
1 - вы не поняли. ))) Ниже напишу ещё разок подробно.

(13) Нет. Есть свой скрипт, который мне очень нравится всем, кроме одного.

Этот скрипт раз в сутки делает полную резервную копию и отсылает её на удалённый сервер rsync. База весит 25 гб, почти все 25 гб  - летят на удалённый сервер.
Потом каждый час делает инкрементную копию и отправляет её туда же.  Всё прекрасно, кроме того, что 25 гб отправляются 4 часа, а кроме них ещё есть кому отправлять данные в это время.

(13) я знаю, что такое shadow copy, знаю, как работает rsync. у автора один файл и он его заменяет в пункте назначения. если уж очень хочется - пусть делает бэкап скулем, восстанавливает в соседнюю базу, делает её детач и rsync'ит сколько угодно. Причины возможной потери консистентности я описал в (9). а полагаться на то, что транзакции ntfs = транзакции скуля я бы не стал, особенно учитывая возможный размер транзакции скуля, как по времени, так и по объему данных.

(14) Тогда у вас ошибка в другом: если исходить из теории ограничения систем в любой проблеме нужно устранять бутылочное горлышко. Ваше бутылочное горлышко - это удаленный сервер с плохим каналом. Или откажитесь от такого решения или поменяйте канал.

(15) Такой вариант тоже нужно попробовать. Но после преобразования mdf ->bak > mdf - последний, скорее всего, будет отличаться от первого.

Я уже изгуглил многое, но пока я не нашёл как скопировать базу mssql не выгружая её в bak.

Дэтач - понятно. Но это надо выгонять пользователей, что невозможно.

(14) погоди, а вторая-третья база у тебя получается рид-онли?

(18) я писал только про одну

(17) > Я уже изгуглил многое, но
log shipping

(19) В чём цель экспериментов? Возможно, есть другие щадящие пути.

(20) Тема, да

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

В целом ясно. Всем спасибо.

(5) ты уж определись, в чем смысл половых сношений в:
Схема Comp1------------INTERNET---------Comp2

и исходя из реальной потребности выбери порядок и протокол работы.
можно же атомарные изменения слать как в (20). или еще какие варианты репликации и зеркалирования поставить. еще можно угореть и настроить Группы доступности AlwaysOn.
все исходя из реальной задачи.