SQL Server Доставка на трупи: Пълно ръководство за администратори на бази данни [2026]

SQL Server Доставката на логове е автоматизирано решение за възстановяване след бедствия, което поддържа резервни копия на вашите производствени бази данни. Технологията прехвърля резервни копия на логове на транзакции от основна база данни на основен сървърен екземпляр към една или повече вторични бази данни на отделни вторични сървърни екземпляри, като гарантира, че вашите вторични бази данни остават синхронизирани с основната база данни, осигурявайки защита срещу загуба на данни и сървърни повреди.

1.2 Цел и предимства на превоза на дървени трупи

Доставката на лог файлове служи за множество важни цели при администрирането на бази данни:

Основната му роля е възстановяване след бедствия, осигурявайки надеждна цел за превключване при срив, когато основният ви сървър стане недостъпен поради хардуерен отказ, софтуерна повреда или катастрофални събития, засягащи вашия център за данни.
Освен това е рентабилно решение с висока наличностЗа разлика от функциите от корпоративен клас, които изискват скъпо лицензиране, доставката на лог файлове работи с SQL Server Стандартно издание, което го прави достъпно за организации с бюджетни ограничения.
Вторичните бази данни в режим на готовност предлагат допълнителна стойност отвъд възстановяването след бедствие. Администраторите на бази данни могат да ги използват за отчитане само за четене, като по този начин разтоварват производствения сървър от заявки.
Функцията за отложено възстановяване осигурява защита срещу случайни промени в данните. Чрез конфигуриране на забавяне на възстановяването създавате времеви прозорец за възстановяване от потребителски грешки, преди разрушителните промени да достигнат до вашата вторична база данни.

2. SQL Server Компоненти и работен процес за доставка на трупи

Превозът на дървени трупи се състои от следните компоненти:

Основен сървър и основна база данни: Основният сървър представлява вашата производствена SQL Server екземпляр, изпълняващ основната база данни.
Споделяне на резервни копия: Междинното място за съхраняване и прехвърляне на резервни копия на регистрационните файлове на транзакциите от основния сървър към вторичните сървъри.
Вторични сървъри и вторични бази данни: Вторичните сървъри хостват копията на вашата основна база данни в режим на готовност.
Сървър за мониторинг (по избор): Този сървър проследява историята и състоянието на всички операции по архивиране, копиране и възстановяване в цялата ви топология за доставка на лог файлове.
Задачи на агенти: Включително задания за архивиране, копиране, възстановяване и предупреждаване, автоматизирайки целия процес на изпращане на лог файлове.

Работният процес за автоматизация е:

Заданието за архивиране се изпълнява на основния сървър и създава резервни копия на регистрационните файлове на транзакциите на основната база данни в споделеното резервно копие.
Заданието за копиране се изпълнява на всеки вторичен сървър и прехвърля архивни файлове с лог файлове от споделеното резервно копие към вторичния(ите) сървър(и).
Заданието за възстановяване се изпълнява на всеки вторичен сървър и прилага копирани резервни копия на регистрационния файл на транзакциите към вторичната база данни.
Заданието за предупреждение се изпълнява на сървъра за наблюдение и проверява дали операциите по архивиране и възстановяване са завършени в рамките на приемливи срокове.

3. Предварителни изисквания

3.1 SQL Server Изисквания за версията

Доставката на дървени трупи е възможна от SQL Server 2000 г. и остава поддържана във всички следващи версии от SQL Server 2005 до 2025 г. Тази дългогодишна подкрепа демонстрира стабилността и продължаващата актуалност на технологията.

3.2 SQL Server Изисквания за изданието

Доставката на лог файлове работи със Standard, Workgroup, Enterprise и Developer издания на SQL ServerТази широка поддръжка на изданията прави изпращането на лог файлове достъпно за организации без лицензи за Enterprise Edition, за разлика от функции като Винаги включени групи за наличност които изискват издания Enterprise или Evaluation.

Забележка: Express Edition не поддържа доставка на лог файлове.

3.3 Изисквания към модела за възстановяване на базата данни

Изпращането на лог файлове изисква основната база данни да използва модел за пълно възстановяване или модел за възстановяване с групово регистриране. Опростеният модел за възстановяване не се поддържа, защото SQL Server автоматично съкращава регистрационните файлове на транзакциите, прекъсвайки непрекъснатата верига от регистрационни файлове, необходима за изпращането им.

За повече подробности относно моделите за възстановяване вижте нашите изчерпателно ръководство за SQL Server резервно копие.

4. Конфигуриране на доставката на лог файлове с помощта на SSMS

4.1 Създаване на папка за споделяне на резервни копия

Преди да конфигурирате изпращането на лог файлове, подгответе папката за споделяне на резервни копия, където ще се съхраняват и прехвърлят резервните копия на лог файловете на транзакциите.

На основния сървър или на специален файлов сървър създайте папка (напр. C:\Архивиране)
Щракнете с десния бутон върху папката и изберете Имоти
Кликнете върху менюто Споделяне етикет
Кликнете Разширено споделяне
Проверка Споделете тази папка
Кликнете Разрешения и грант Пълен контрол разрешение на SQL Server акаунт за услуги NT услуга\MSSQLSERVER.
Кликнете OK да кандидатствате.
Документирайте мрежовия път (UNC) (напр. \\ИМЕН-НА-СЪРВЪР\Архивиране)

4.2 Активиране и конфигуриране на изпращането на лог файлове

Щракнете с десния бутон върху основната база данни и изберете Имоти.
В Свойства на базата данни диалоговия прозорец, изберете Доставка на дневник на транзакциите страница в левия панел.
Проверка Активирайте това като основна база данни в конфигурация за изпращане на лог файлове за да се активира доставката на дневници.
След това можете да конфигурирате настройките за архивиране, вторичния сървър и сървъра за наблюдение на тази страница със свойства. Ще ги представим в следващите подраздели.

4.2.1 Конфигуриране на настройките за архивиране

Кликнете върху менюто Настройки за архивиране бутон
В Настройки за архивиране на регистрационния файл на транзакциите диалогов прозорец, под Мрежов път до папката за архивиране въведете UNC пътя (напр. \\ИМЕН-НА-СЪРВЪР\Архивиране)
Ако папката за архивиране се намира на основния сървър, въведете локалния път (напр. C:\Архивиране)
Конфигурирайте други настройки, като например период на съхранение на резервното копие, праг на предупреждение, задание за архивиране и компресия.
Кликнете OK за да потвърдите настройките и да затворите диалоговия прозорец.

4.2.2 Конфигуриране на екземпляр на вторичен сървър и база данни

Кликнете върху ДОБАВЯНЕ, под Вторични сървърни екземпляри и бази данни
В Настройки на вторичната база данни кликнете върху Свързване за свързване с екземпляра на вторичния сървър.
В Вторична база данни падащо меню, изберете съществуваща база данни или въведете ново име на база данни
В Инициализиране на вторичната база данни , изберете Да, генерирайте пълно резервно копие на основната база данни и я възстановете във вторичната база данни (и създайте вторичната база данни, ако тя не съществува)
Кликнете върху менюто Копиране на файлове етикет
В Целева папка за копирани файлове (Тази папка обикновено се намира на вторичния сървър), въведете локалния път на целевата папка на вторичния сървър.
Уверете се, че папката съществува и SQL Server акаунтът за услуги има разрешения за запис
Кликнете OK за да потвърдите настройките и да затворите диалоговия прозорец.

4.2.3 Конфигуриране на сървър за наблюдение

Проверка Използвайте екземпляр на сървър за наблюдение
Кликнете на Настройки.
Кликнете Свързване за свързване с екземпляра на сървъра за наблюдение
комплект Изтриване на историята след да се посочи период на съхранение в часове
Кликнете OK за да потвърдите настройките и да затворите диалоговия прозорец.

4.2.4 Преглед и завършване на конфигурацията

Прегледайте всички настройки на Доставка на дневник на транзакциите страница
Проверете настройките за архивиране, конфигурациите на вторичния сървър и настройките за наблюдение
Кликнете OK за да приложите конфигурацията
Съветникът създава всички необходими задачи на първични, вторични и мониторни сървъри
Кликнете Затвори когато конфигурацията приключи

5. Предимства и недостатъци на превоза на дървени трупи

5.1 Ползи от SQL Server Доставка на дървени трупи

Рентабилно решение: Работи с SQL Server Стандартно издание, което елиминира скъпите изисквания за лицензиране на Enterprise Edition. Това прави надеждното възстановяване след бедствия достъпно за организации с ограничен бюджет.
Лесно за конфигуриране и поддръжка: Съветникът за конфигуриране насочва администраторите през процеса на настройка с ясни опции. Повечето бази данни могат да бъдат конфигурирани в рамките на 15-30 минути без специализирано обучение.
Поддръжка на множество вторични сървъри: Поддържайте множество вторични сървъри без архитектурни ограничения. Разположете един вторичен за локално възстановяване след бедствия, друг отдалечено и трети за отчитане.
Минимално въздействие върху основния сървър: Работи асинхронно, елиминирайки разходите за синхронизация на основния сървър. Времето за потвърждаване на транзакциите остава непроменено.
Използва съществуващи резервни копия на регистрационните файлове на транзакциите: Архивните копия за доставка на лог файлове са стандартни архивни копия на лог файлове на транзакции, които могат да се използват за възстановяване към определен момент, независимо от доставката на лог файлове.
Опция за отложено възстановяване: Функцията за забавяне на възстановяването осигурява защита срещу случайни промени в данните, която не е налична в решения за репликация в реално време.
Не се изисква споделено хранилище: Използва независимо съхранение на всеки сървър, елиминирайки изискванията за споделено съхранение и свързаните с това разходи.
Поддръжка на различни платформи: Работи идентично както на Windows, така и на Linux SQL Server разгръщания.
Работи в различни домейни: Не изисква доверителни отношения на домейн или интеграция с Active Directory.

5.2 Недостатъци и ограничения на превоза на дървени трупи

Няма автоматично превключване при срив: Основното ограничение е изискването за ръчно превключване при срив. Администраторите трябва да изпълнят няколко стъпки, преди услугата да се възобнови.
Закъснение при синхронизиране на данни: Вторичните бази данни винаги изостават от първичните бази данни по честотата на архивиране и възстановяване.
Само конфигурация на ниво база данни: Конфигурира на ниво база данни, а не на ниво екземпляр. Защитата на 50 бази данни изисква 50 отделни конфигурации.
Ръчни промени в низа за свързване: Приложенията трябва да актуализират низовете за свързване, за да сочат към вторичния сървър след превключване при срив.
Вторични прекъсвания на базата данни: Вторичните бази данни в режим на готовност изключват потребителите по време на операции по възстановяване.
Отделно управление на бази данни: Всяка конфигурация на базата данни трябва да се управлява индивидуално, без координирани възможности за управление.

6. Най-добри практики и случаи на употреба

6.1 Кога да използвате доставка на трупи

Нискобюджетно възстановяване след бедствия: Представя се като рентабилно решение за възстановяване след бедствия за организации, които не могат да оправдаят разходите за лицензиране на Enterprise Edition.
Умерени изисквания за RPO/RTO: Приложенията, които толерират 15-30 минути загуба на данни и 30-60 минути престой, са идеално съобразени с неговите възможности.
Сървър за отчитане само за четене: Създавайте копия само за четене за отчетни натоварвания, които толерират периодични прекъсвания на връзката.
Стандартни издания: Организации, стандартизирани по SQL Server Стандартното издание няма достъп до групите за наличност „Always On“, което прави изпращането на лог файлове най-добрият наличен вариант.
Проекти за миграция на сървъри: Улеснява миграциите на сървъри, като поддържа синхронизирани копия по време на преходни периоди.
Изисквания за забавени данни: Конфигурирайте закъснения за възстановяване, за да поддържате базите данни във фиксирани точки в миналото за целите на съответствието или одита.

6.2 Кога НЕ е необходимо да се използва доставка на трупи

Изисквания за почти нулев престой: Приложенията с изисквания за RTO под 15 минути не могат да разчитат на ръчно превключване при срив.
Необходимо е автоматично превключване при срив: Неподходящо, когато бизнес изискванията налагат автоматично превключване при срив без намесата на администратор.
Необходима е синхронизация в реално време: Приложенията, изискващи данни в реално или почти реално време на вторични сървъри, не могат да приемат присъщото забавяне на доставката на лог файлове.
Минимална толерантност към загуба на данни: Организациите, чийто RPO се измерва в секунди или изискват нулева загуба на данни, се нуждаят от синхронни решения.

6.3 най-добри практики

Оптимизация на честотата на резервно копие: Балансирайте честотата на архивиране спрямо системните разходи и целите за възстановяване. Започнете с 15-минутни интервали и ги коригирайте въз основа на реалните изисквания.
Съображения за мрежовия път: Използвайте UNC пътища, а не картографирани устройства за местоположения за архивиране. Поставете споделените резервни копия в надеждна мрежова инфраструктура.
Настройка на мониторинг и предупреждения: Конфигурирайте известия за неуспехи на задачи за архивиране, копиране и възстановяване веднага след завършване на настройката за изпращане на лог файлове.
График за редовно тестване: Планирайте тримесечни или полугодишни тестове за превключване на резервни компоненти, за да валидирате процедурите и да поддържате готовността на администратора.
Поддръжка на документация: Поддържайте подробни наръчници с инструкции, документиращи подробности за конфигурацията, процедурите за превключване при срив и стъпките за отстраняване на неизправности.
Съображения за сигурност: Използвайте специални сервизни акаунти с минимално необходими разрешения. Ограничете разрешенията за споделяне в мрежата по подходящ начин.
Управление на дисковото пространство: Непрекъснато следете дисковото пространство на резервните копия. Конфигурирайте известия, когато пространството падне под 20%.
Конфигурация на политиката за съхранение: Задайте периоди на съхранение на резервни копия, по-дълги от максимално допустимото забавяне на синхронизацията.
Забавяне на възстановяването за защита: Конфигурирайте закъснения за възстановяване, когато защитата срещу случайни промени оправдава увеличеното забавяне на синхронизацията.

7. Отстраняване на често срещани проблеми

7.1 Неуспешни задачи за архивиране

Недостатъчно дисково пространство: Проверете историята на задачите за грешки, свързани с дисковото пространство. Проверете наличното и свободното пространство, като изтриете стари резервни копия или активирате компресията.
Проблеми с разрешенията: Проверете SQL Server Сервизният акаунт има разрешения за пълен контрол както за локалната папка, така и за споделения мрежов ресурс.
Базата данни не е напълно възстановена: Върнете се към модел за пълно възстановяване и направете пълно архивиране, за да рестартирате веригата от регистрационни файлове на транзакциите.

7.2 Неуспешни задачи за копиране

Мрежовият път е недостъпен: Тествайте свързаността от вторичния сървър, като ръчно картографирате мрежовия път.
Проблеми с удостоверяването: Конфигурирайте изрични идентификационни данни за достъп до мрежови споделени ресурси, ако сървърите са в различни домейни.
Проблеми със заключването на файлове: Изключете папката с резервни копия от антивирусното сканиране в реално време, за да предотвратите заключване на файлове.

7.3 Неуспешни задачи за възстановяване

Липсващи резервни файлове: Проверете дали файловете съществуват в целевата папка и проверете историята на заданията за копиране.
Грешка при възстановяване на последователност: Идентифицирайте липсващите резервни копия на регистрационните файлове на транзакциите и ги възстановете последователно, за да поправите веригата от регистрационни файлове.
Базата данни е в грешно състояние: Реинициализирайте изпращането на лог файлове, като възстановите пълно архивиране с NORECOVERY, ако някой е възстановил базата данни.
Повреда на файловете в базата данни: Ако неуспехите при възстановяване продължават въпреки правилната последователност и конфигурация, самите файлове на базата данни може да са повредени. В такива случаи може да се наложи да използвате специализиран инструмент за възстановяване на sql за да извлечете данни от повредените .MDF и .NDF файлове, преди да се опитате да реинициализирате доставката на лог файлове.

7.4 Проблеми със забавянето на синхронизацията

Ограничения на мрежовата честотна лента: Активирайте компресиране на резервни копия, за да намалите размера на файловете и изискванията за честотна лента.
Висок обем на транзакциите: Помислете за увеличаване на честотата на архивиране, за да създадете по-малки и по-лесно управляеми архивни файлове.
Недостатъчна честота на възстановяване: Увеличете честотата на задачите за възстановяване, за да доближите честотата на архивиране и да минимизирате забавянето.

7.5 Проблеми със свързаността на сървъра при наблюдение (SQL 2025)

Грешки на доставчика на OLE DB: SQL Server Задължителното криптиране по подразбиране от 2025 г. е в конфликт с по-стари екземпляри, на които липсва правилна конфигурация за криптиране.
Несъответствие в конфигурацията на криптирането: Проверете конфигурацията на свързания сървър на мониторния сървър и проверете настройките за криптиране.
Решения за заобикаляне: Премахнете и пресъздайте доставката на лог файлове, използвайки TLS 1.3 параметри, или надстройте всички екземпляри до SQL Server 2025.

7.6 SQL Server Проблеми с обслужването на агенти

Услугата не е стартирана: Проверете състоянието на услугата на агента и я конфигурирайте да се стартира автоматично.
Графикът на заданието е деактивиран: Проверете състоянието на графика на заданието и активирайте деактивираните графици.
Неуспешни стъпки в задачата: Прегледайте историята на задачите, за да идентифицирате неуспешни стъпки и конкретни съобщения за грешки.

8. Често задавани въпроси (FAQ)

В: Мога ли да използвам доставка на дневници с Express Edition?

О: Не, SQL Server Express Edition не поддържа доставка на лог файлове, тъй като липсва SQL Server Агент.

В: Колко често трябва да планирам архивиране на лог файлове?

A: Интервалите от 15 минути по подразбиране осигуряват разумен баланс. Настройте ги въз основа на вашата цел за точка на възстановяване.

В: Могат ли вторични бази данни да се използват за отчитане?

A: Да, вторичните бази данни, конфигурирани в режим на готовност, позволяват достъп само за четене между операциите по възстановяване.

В: Какво се случва, ако основният сървър се повреди?

A: Изпълнете ръчно превключване при срив, за да превключите вторичната база данни онлайн. Загубата на данни е равна на забавянето на синхронизацията по време на срив.

В: Мога ли да имам няколко вторични сървъра?

A: Да, доставката на лог файлове поддържа неограничен брой вторични сървъри с независими конфигурации.

В: Как да изчисля забавянето на синхронизацията?

A: Сравнете последния възстановен времеви отпечатък на дневника на транзакциите с текущото време, като използвате таблици за наблюдение на доставката на дневници.

В: Може ли доставката на лог файлове да работи между различни домейни?

A: Да, работи в различни домейни или в работни групи, без да изисква доверителни отношения.

В: Каква е разликата между режим „Без възстановяване“ и режим „В готовност“?

A: Няма режим на възстановяване, който да държи базата данни недостъпна. Режимът на готовност позволява заявки само за четене между възстановяванията.

В: Мога ли временно да спра доставката на дневници?

A: Да, деактивирайте заданията за архивиране, копиране и възстановяване, за да поставите синхронизацията на пауза, като същевременно запазите конфигурацията.

В: Как да премахна конфигурацията за доставка на лог файлове?

О: В Доставка на дневник на транзакциите страница на имота:

Махнете отметката от Активирайте това като основна база данни в конфигурация за изпращане на лог файлове
Кликнете OK за да премахнете конфигурацията и да изтриете заданията.

В: Мога ли да превключа вторичната база данни в режим на четене и запис?

A: Да, изпълнява се RESTORE DATABASE WITH RECOVERY, но това прекъсва веригата за доставка на лог файлове.

В: Какво е максималното забавяне, което мога да конфигурирам за възстановяване?

A: Няма твърдо ограничение. Конфигурирайте закъснения от минути до дни въз основа на вашите изисквания за защита.

В: Как доставката на лог файлове влияе върху стратегията за архивиране?

A: Създава резервни копия на регистрационни файлове на транзакции, които могат да се използват както за изпращане на регистрационни файлове, така и за възстановяване в определен момент.

В: Мога ли да използвам доставка на лог файлове за миграция на сървъра?

A: Да, конфигурирайте изпращането на лог файлове до новия сървър, синхронизирайте, след което извършете планирано превключване на стария сървър при срив по време на поддръжка.

В: Какви инструменти за мониторинг работят с доставката на трупи?

A: SQL Server Management Studio включва вградени отчети. Инструменти на трети страни, като SQL Monitor и SolarWinds, осигуряват подобрено наблюдение.

9. Заключение и препоръки

9.1 Обобщение на ключовите точки

SQL Server Доставката на лог файлове осигурява надеждно и рентабилно възстановяване след бедствия чрез автоматизирани операции по архивиране и възстановяване на лог файловете на транзакциите. Технологията работи със Standard Edition, изисква минимална инфраструктура и поддържа множество вторични сървъри.

Доставката на лог файлове е отлична за умерени цели за възстановяване, където ръчното превключване при срив е приемливо. Ключовите ограничения включват изискване за ръчно превключване при срив, забавяне на синхронизацията и обхват на конфигурация на ниво база данни.

Технологията се интегрира добре със съществуващите стратегии за архивиране, поддържа отчитане само за четене през режим на готовност и осигурява защита от отложено възстановяване срещу случайни промени.

9.2 Вземане на правилния избор за вашата среда

Оценете доставката на лог файлове спрямо вашите специфични изисквания преди внедряването. Вземете предвид целите за точки на възстановяване, целите за време за възстановяване, бюджетните ограничения и толерантността към оперативна сложност.

Организации, които използват SQL Server Стандартното издание с умерени изисквания за възстановяване трябва сериозно да обмисли изпращането на лог файлове. Предприятията със строг RTO под 15 минути трябва да оценят групите за достъпност Always On.

Обмислете хибридни подходи, комбиниращи превоз на дървени трупи с други технологии за оптимизиране на разходите, като същевременно отговаряте на разнообразни изисквания.

9.3 Следващи стъпки и допълнителни ресурси

Започнете с малки пилотни внедрявания, за да натрупате опит. Разработете подробна документация, включително подробности за конфигурацията, процедури за превключване при срив и ръководства за отстраняване на неизправности.

Планирайте редовни тестове за превключване на резервни части, за да валидирате процедурите и да поддържате готовността на администратора. Бъдете в крак с SQL Server актуализации и подобрения.

Източници

Официален документ на Microsoft: Относно доставката на дървени трупи (SQL Server)
Официален документ на Microsoft: Конфигуриране на доставката на дневници (SQL Server)

За автора

Юан Шенг е старши администратор на бази данни (DBA) с над 10 години опит в SQL Server среди и управление на корпоративни бази данни. Той е разрешил успешно стотици сценарии за възстановяване на бази данни във финансови услуги, здравеопазване и производствени организации.

Юан е специализиран в SQL Server възстановяване на бази данни, решения за висока достъпност и оптимизация на производителността. Неговият богат практически опит включва управление на многотерабайтови бази данни, внедряване на групи за достъпност Always On и разработване на автоматизирани стратегии за архивиране и възстановяване за критично важни бизнес системи.

Чрез техническата си експертиза и практичен подход, Юан се фокусира върху създаването на изчерпателни ръководства, които помагат на администраторите на бази данни и ИТ специалистите да решават сложни задачи. SQL Server предизвикателствата ефикасно. Той е в крак с най-новото SQL Server издания и развиващите се технологии за бази данни на Microsoft, като редовно тества сценарии за възстановяване, за да гарантира, че препоръките му отразяват най-добрите практики в реалния свят.

Имате въпроси относно SQL Server възстановяване или имате нужда от допълнителни насоки за отстраняване на проблеми с базата данни? Юан приветства обратна връзка и предложения за подобряване на тези технически ресурси.