SQL Server Přeprava protokolů: Kompletní průvodce pro správce databází [2026]

1. Úvod do SQL Server Přeprava klád

1.1 Co je SQL Server Doprava klád?

SQL Server Log Shipping je automatizované řešení pro zotavení po havárii, které udržuje teplé pohotovostní kopie vašich produkčních databází. Technologie přenáší zálohy transakčních protokolů z primární databáze na instanci primárního serveru do jedné nebo více sekundárních databází na samostatných instancích sekundárních serverů, čímž zajišťuje synchronizaci vašich sekundárních databází s primární databází a poskytuje ochranu před ztrátou dat a selháním serveru.

1.2 Účel a výhody přepravy klád

Odesílání protokolů slouží v rámci správy databází několika klíčovým účelům:

• Jeho primární rolí je obnova po havárii a poskytování spolehlivého cíle pro přepnutí na záložní server, když se váš primární server stane nedostupným kvůli selhání hardwaru, poškození softwaru nebo katastrofickým událostem ovlivňujícím vaše datové centrum.
• Je to také nákladově efektivní řešení s vysokou dostupnostíNa rozdíl od funkcí podnikové úrovně, které vyžadují drahé licencování, funguje doručování protokolů s SQL Server Standardní edice, která je přístupná i organizacím s omezeným rozpočtem.
• Sekundární databáze v pohotovostním režimu nabízejí další hodnotu nad rámec zotavení z havárie. Správci databází je mohou používat pro vytváření sestav pouze pro čtení, čímž odlehčují pracovní zátěž dotazů z produkčního serveru.
• Funkce odložené obnovy poskytuje ochranu před nechtěnými úpravami dat. Konfigurací odkladu obnovy vytvoříte časové okno pro zotavení z chyb uživatelů, než se destruktivní změny dostanou do vaší sekundární databáze.

2. SQL Server Komponenty a pracovní postup pro přepravu protokolů

Přeprava klád se skládá z následujících komponent:

• Primární server a primární databáze: Primární server představuje vaši produkční síť. SQL Server instance s primární databází.
• Sdílená záloha: Mezilehlé umístění pro ukládání a přenos záloh transakčních protokolů z primárního serveru na sekundární servery.
• Sekundární servery a sekundární databáze: Sekundární servery hostují teplé pohotovostní kopie vaší primární databáze.
• Monitorovací server (volitelné): Tento server sleduje historii a stav všech operací zálohování, kopírování a obnovy v celé topologii odesílání protokolů.
• Úlohy agenta: Včetně úloh zálohování, kopírování, obnovy a upozornění, automatizace celého procesu odesílání protokolů.

Automatizační pracovní postup je:

1. Úloha zálohování se spustí na primárním serveru a vytvoří zálohy transakčních protokolů primární databáze na sdílené záložní složce.
2. Úloha kopírování se spustí na každém sekundárním serveru a přenese záložní soubory protokolů ze sdílené zálohy na sekundární server(y).
3. Úloha obnovení se spustí na každém sekundárním serveru a použije zkopírované zálohy transakčních protokolů na sekundární databázi.
4. Úloha upozornění se spustí na monitorovacím serveru a kontroluje, zda jsou operace zálohování a obnovy dokončeny v přijatelných časových rámcích.

3. Předpoklady a požadavky

3.1 SQL Server Požadavky na verzi

Přeprava klád je k dispozici od roku SQL Server 2000 a zůstává podporována ve všech následujících verzích od SQL Server 2005 až 2025. Tato dlouhodobá podpora dokazuje stabilitu a trvalou relevantnost technologie.

3.2 SQL Server Požadavky na vydání

Odesílání protokolů funguje s edicemi Standard, Workgroup, Enterprise a Developer. SQL ServerTato široká podpora edic umožňuje organizacím bez licencí Enterprise Edition odesílat protokoly, na rozdíl od funkcí, jako je Vždy dostupné skupiny dostupnosti které vyžadují edice Enterprise nebo Evaluation.

Poznámka: Express Edition nepodporuje odesílání protokolů.

3.3 Požadavky na model obnovy databáze

Odesílání protokolů vyžaduje, aby primární databáze používala model úplné obnovy nebo model hromadné obnovy. Jednoduchý model obnovy není podporován, protože SQL Server automaticky zkracuje transakční protokoly, čímž přerušuje nepřetržitý řetězec protokolů potřebný pro jejich odesílání.

Více informací o modelech obnovy naleznete v našich komplexní průvodce SQL Server zálohování.

4. Konfigurace odesílání protokolů pomocí SSMS

4.1 Vytvoření složky pro sdílení záloh

Před konfigurací odesílání protokolů připravte sdílenou složku záloh, kam budou zálohy protokolů transakcí uloženy a přenášeny.

1. Na primárním serveru nebo vyhrazeném souborovém serveru vytvořte složku (např. C:\Záloha)
2. Klepněte pravým tlačítkem na složku a vyberte Nemovitosti
3. Klepněte na tlačítko Sdílení Karta
4. klikněte Pokročilé sdílení
5. Kontrola Sdílej tuto složku
6. klikněte Oprávnění a grant Úplné řízení povolení k SQL Server servisní účet Služba NT\MSSQLSERVER.
7. klikněte OK použít.
8. Zdokumentujte síťovou cestu (UNC) (např. \\NÁZEV-SERVERU\Záloha)

4.2 Povolení a konfigurace odesílání protokolů

1. Klikněte pravým tlačítkem myši na primární databázi a vyberte Nemovitosti.
2. v Vlastnosti databáze v dialogovém okně vyberte Doprava protokolu transakcí stránka v levém panelu.
3. Kontrola Povolit jako primární databázi v konfiguraci odesílání protokolů pro povolení odesílání protokolů.
4. Pak můžete na této stránce vlastností nakonfigurovat nastavení zálohování, sekundární server a monitorovací server. Představíme si je v následujících podkapitolách.
   
   

4.2.1 Konfigurace nastavení zálohování

1. Klepněte na tlačítko Nastavení zálohování tlačítko
   
2. v Nastavení zálohování protokolu transakcí dialogové okno, pod Síťová cesta ke složce zálohy zadejte cestu UNC (např. \\NÁZEV-SERVERU\Záloha)
3. Pokud se záložní složka nachází na primárním serveru, zadejte lokální cestu (např. C:\Záloha)
4. Nakonfigurujte další nastavení, jako je doba uchovávání záloh, prahová hodnota upozornění, úloha zálohování a komprese.
5. klikněte OK pro potvrzení nastavení a zavření dialogového okna.
   

4.2.2 Konfigurace instance sekundárního serveru a databáze

1. klikněte přidat pod Instance sekundárních serverů a databáze
2. v Nastavení sekundární databáze dialog, klepněte na tlačítko mítinky Connect pro připojení k instanci sekundárního serveru.
3. v Sekundární databáze rozbalovací seznam vyberte existující databázi nebo zadejte nový název databáze
4. v Inicializace sekundární databáze vyberte kartu Ano, vygenerovat úplnou zálohu primární databáze a obnovit ji do sekundární databáze (a vytvořit sekundární databázi, pokud neexistuje)
   
5. Klepněte na tlačítko Kopírovat soubory Karta
6. v Cílová složka pro kopírované soubory (tato složka se obvykle nachází na sekundárním serveru), zadejte lokální cestu k cílové složce na sekundárním serveru.
7. Ujistěte se, že složka existuje a SQL Server servisní účet má oprávnění k zápisu
   
8. klikněte OK pro potvrzení nastavení a zavření dialogového okna.

4.2.3 Konfigurace monitorovacího serveru

1. Kontrola Použití instance monitorovacího serveru
   
   
2. klikněte Nastavení
3. klikněte mítinky Connect pro připojení k instanci monitorovacího serveru
4. sada Smazat historii po specifikovat dobu uchování v hodinách
5. klikněte OK pro potvrzení nastavení a zavření dialogového okna.
   
   

4.2.4 Kontrola a dokončení konfigurace

1. Zkontrolujte všechna nastavení na Doprava protokolu transakcí strana
2. Ověřte nastavení zálohování, konfigurace sekundárního serveru a nastavení monitorování
3. klikněte OK použít konfiguraci
4. Průvodce vytvoří všechny potřebné úlohy na primárních, sekundárních a monitorovacích serverech.
5. klikněte zavřít po dokončení konfigurace

5. Výhody a nevýhody přepravy klád

5.1 Výhody SQL Server Přeprava klád

• Cenově efektivní řešení: Pracuje s SQL Server Standardní edice, která eliminuje drahé licenční požadavky pro Enterprise edici. Díky tomu je spolehlivá obnova po havárii dostupná i pro organizace s omezeným rozpočtem.
• Jednoduchá konfigurace a údržba: Průvodce konfigurací provede administrátory nastavením s přehlednými možnostmi. Většinu databází lze nakonfigurovat během 15–30 minut bez specializovaného školení.
• Podpora více sekundárních serverů: Podporujte řadu sekundárních serverů bez architektonických omezení. Nasaďte jeden sekundární server pro lokální zotavení po havárii, druhý vzdáleně a třetí pro reporting.
• Minimální dopad na primární server: Pracuje asynchronně, čímž eliminuje synchronizační režii na primárním serveru. Doby potvrzení transakcí zůstávají nezměněny.
• Používá existující zálohy protokolu transakcí: Zálohy pro odesílání protokolů jsou standardní zálohy transakčních protokolů, které lze použít pro obnovení v daném okamžiku nezávisle na odesílání protokolů.
• Možnost odloženého obnovení: Funkce zpoždění obnovení poskytuje ochranu před náhodnými úpravami dat, která není k dispozici v řešení replikace v reálném čase.
• Není vyžadováno sdílené úložiště: Používá nezávislé úložiště na každém serveru, čímž eliminuje požadavky na sdílené úložiště a související náklady.
• Podpora napříč platformami: Funguje stejně na Windows i Linuxu SQL Server nasazení.
• Funguje napříč doménami: Nevyžaduje vztahy důvěryhodnosti domény ani integraci služby Active Directory.

5.2 Nevýhody a omezení přepravy klád

• Žádné automatické přepnutí při selhání: Hlavním omezením je požadavek na ruční přepnutí služeb při selhání. Administrátoři musí před obnovením služby provést několik kroků.
• Zpoždění synchronizace dat: Sekundární databáze vždy zaostávají za primárními databázemi v četnosti zálohování a obnovování.
• Pouze konfigurace na úrovni databáze: Konfiguruje na úrovni databáze, nikoli na úrovni instance. Ochrana 50 databází vyžaduje 50 samostatných konfigurací.
• Ruční změny připojovacího řetězce: Aplikace musí po převzetí služeb při selhání aktualizovat připojovací řetězce tak, aby odkazovaly na sekundární server.
• Přerušení sekundární databáze: Sekundární databáze v pohotovostním režimu odpojují uživatele během operací obnovy.
• Samostatná správa databází: Každá konfigurace databáze musí být spravována individuálně bez koordinovaných funkcí správy.

6. Nejlepší postupy a případy použití

6.1 Kdy použít přepravu protokolů

• Nízkorozpočtová obnova po havárii: Vyniká jako cenově dostupné řešení pro obnovu po havárii pro organizace, které si nemohou dovolit náklady na licencování Enterprise Edition.
• Střední požadavky na RPO/RTO: Aplikace, které tolerují 15–30 minut ztráty dat a 30–60 minut výpadku, dokonale odpovídají jeho možnostem.
• Server pro vytváření sestav pouze pro čtení: Vytvořte kopie jen pro čtení pro úlohy vytváření sestav, které tolerují pravidelná odpojení.
• Prostředí standardní edice: Organizace standardizované na SQL Server Standardní edice nemá přístup ke skupinám dostupnosti Always On, takže odesílání protokolů je nejlepší dostupnou možností.
• Projekty migrace serverů: Usnadňuje migraci serverů udržováním synchronizovaných kopií během přechodných období.
• Požadavky na zpožděná data: Nakonfigurujte zpoždění obnovení tak, aby databáze zůstaly v pevných bodech v minulosti pro účely dodržování předpisů nebo auditu.

6.2 Kdy NEPOUŽÍVAT přepravu klád

• Požadavky na téměř nulové prostoje: Aplikace s požadavky na RTO kratšími než 15 minut se nemohou spoléhat na ruční přepnutí služeb při selhání.
• Potřebné automatické přepnutí při selhání: Nevhodné, pokud obchodní požadavky vyžadují automatické přepnutí při selhání bez zásahu administrátora.
• Synchronizace v reálném čase je vyžadována: Aplikace vyžadující data v reálném čase nebo téměř v reálném čase na sekundárních serverech nemohou akceptovat inherentní zpoždění způsobené odesíláním protokolů.
• Minimální tolerance ztráty dat: Organizace s RPO měřeným v sekundách nebo vyžadující nulovou ztrátu dat potřebují synchronní řešení.

6.3 osvědčených postupů

• Optimalizace frekvence zálohování: Vyvažte frekvenci zálohování s ohledem na režijní náklady systému a cíle obnovy. Začněte s 15minutovými intervaly a upravujte je podle skutečných požadavků.
• Úvahy o síťové cestě: Pro umístění záloh používejte cesty UNC místo mapovaných disků. Sdílené zálohy umisťujte na spolehlivou síťovou infrastrukturu.
• Nastavení monitorování a upozornění: Nakonfigurujte upozornění na selhání úloh zálohování, kopírování a obnovy ihned po dokončení nastavení odesílání protokolů.
• Pravidelný testovací plán: Naplánujte čtvrtletní nebo pololetní testy přepnutí na záložní systém, abyste ověřili postupy a udrželi připravenost administrátorů.
• Údržba dokumentace: Udržujte podrobné runbooky dokumentující podrobnosti o konfiguraci, postupy převzetí služeb při selhání a kroky pro řešení potíží.
• Bezpečnostní aspekty: Používejte vyhrazené servisní účty s minimálními požadovanými oprávněními. Omezte oprávnění sdílených síťových složek odpovídajícím způsobem.
• Správa místa na disku: Neustále sledujte místo na disku v zálohovaných úložištích. Nakonfigurujte upozornění, když místo klesne pod 20 %.
• Konfigurace zásad uchovávání: Nastavte doby uchovávání záloh delší, než je maximální přijatelné zpoždění synchronizace.
• Zpoždění obnovení pro ochranu: Nakonfigurujte zpoždění obnovení, pokud ochrana proti náhodným úpravám odůvodňuje delší zpoždění synchronizace.

7. Odstraňování běžných problémů

7.1 Selhání úloh zálohování

• Nedostatek místa na disku: Zkontrolujte historii úloh, zda se nevyskytly chyby v prostoru na disku. Ověřte dostupné a volné místo smazáním starých záloh nebo povolením komprese.
• Problémy s oprávněním: Ověřte SQL Server Účet služby má oprávnění Úplný přístup k místní složce i síťové sdílené položce.
• Databáze není plně obnovena: Vraťte se zpět na model úplné obnovy a proveďte úplnou zálohu, abyste restartovali řetězec transakčních protokolů.

7.2 Selhání kopírovacích úloh

• Síťová cesta není dostupná: Otestujte připojení ze sekundárního serveru ručním mapováním síťové cesty.
• Problémy s autentizací: Nakonfigurujte explicitní přihlašovací údaje pro přístup ke sdílené síťové položce, pokud se servery nacházejí v různých doménách.
• Problémy se zamykáním souborů: Vyloučte zálohovanou složku z antivirové kontroly v reálném čase, abyste zabránili uzamčení souborů.

7.3 Selhání úlohy obnovení

• Chybějící záložní soubory: Ověřte, zda v cílové složce existují soubory, a zkontrolujte historii kopírování.
• Chyba sekvence obnovení: Identifikujte chybějící zálohy transakčních protokolů a postupně je obnovte, abyste opravili řetězec protokolů.
• Databáze v nesprávném stavu: Znovu inicializujte odesílání protokolů obnovením úplné zálohy pomocí NORECOVERY, pokud někdo obnovil databázi.
• Poškození databázových souborů: Pokud selhání obnovy přetrvává i přes správné pořadí a konfiguraci, mohou být samotné soubory databáze poškozeny. V takových případech může být nutné použít specializovaný nástroj. nástroj pro obnovu SQL extrahovat data z poškozených souborů .MDF a .NDF před pokusem o opětovnou inicializaci odesílání protokolů.

7.4 Problémy se zpožděním synchronizace

• Omezení šířky pásma sítě: Povolte kompresi záloh pro snížení velikosti souborů a požadavků na šířku pásma.
• Vysoký objem transakcí: Zvažte zvýšení frekvence zálohování, abyste vytvořili menší a lépe spravovatelné záložní soubory.
• Nedostatečná frekvence obnovy: Zvyšte frekvenci úloh obnovy na přibližně stejnou frekvenci zálohování a minimalizujte zpoždění.

7.5 Monitorování problémů s připojením k serveru (SQL 2025)

• Chyby poskytovatele OLE DB: SQL Server Výchozí povinné šifrování z roku 2025 konfliktuje se staršími instancemi, které nemají správnou konfiguraci šifrování.
• Neshoda konfigurace šifrování: Ověřte konfiguraci propojeného serveru na monitorovacím serveru a zkontrolujte nastavení šifrování.
• Řešení alternativního řešení: Zrušte a znovu vytvořte odesílání protokolů pomocí parametrů TLS 1.3 nebo upgradujte všechny instance na SQL Server 2025.

7.6 SQL Server Problémy se službou agenta

• Služba nebyla spuštěna: Zkontrolujte stav služby Agent a nakonfigurujte její automatické spuštění.
• Plán úloh zakázán: Ověřte stav plánu úloh a povolte zakázané plány.
• Selhání kroků úlohy: Zkontrolujte historii úloh a identifikujte neúspěšné kroky a konkrétní chybové zprávy.

8. Často kladené otázky (FAQ)

Otázka: Mohu používat expresní verzi pro odesílání protokolů?

A: Ne, SQL Server Express Edition nepodporuje odesílání protokolů, protože jí chybí SQL Server Činidlo.

Otázka: Jak často bych měl/a plánovat zálohy protokolů?

A: Výchozí 15minutové intervaly poskytují rozumnou rovnováhu. Upravte je podle cílového bodu zotavení.

Otázka: Lze pro reporting použít sekundární databáze?

A: Ano, sekundární databáze nakonfigurované v pohotovostním režimu umožňují mezi operacemi obnovy přístup pouze pro čtení.

Otázka: Co se stane, když selže primární server?

A: Proveďte ruční přepnutí služeb při selhání, abyste sekundární databázi uvedli do online režimu. Ztráta dat se rovná synchronizačnímu zpoždění v době selhání.

Otázka: Mohu mít více sekundárních serverů?

A: Ano, doručování protokolů podporuje neomezený počet sekundárních serverů s nezávislými konfiguracemi.

Otázka: Jak vypočítám zpoždění synchronizace?

A: Porovnejte časové razítko posledního obnoveného transakčního protokolu s aktuálním časem pomocí tabulek pro sledování odesílání protokolů.

Otázka: Může odesílání protokolů fungovat napříč různými doménami?

A: Ano, funguje to napříč různými doménami nebo v prostředích pracovních skupin bez nutnosti vztahů důvěryhodnosti.

Otázka: Jaký je rozdíl mezi režimem Bez obnovení a pohotovostním režimem?

A: Žádný režim obnovy neudrží databázi nepřístupnou. Pohotovostní režim umožňuje dotazy pouze pro čtení mezi obnoveními.

Otázka: Mohu dočasně pozastavit odesílání protokolů?

A: Ano, zakažte úlohy zálohování, kopírování a obnovy, abyste pozastavili synchronizaci a zároveň zachovali konfiguraci.

Otázka: Jak odstraním konfiguraci odesílání protokolů?

Odpověď: V Doprava protokolu transakcí stránka s nemovitostmi:

1. Zrušte zaškrtnutí Povolit jako primární databázi v konfiguraci odesílání protokolů
2. klikněte OK pro odstranění konfigurace a smazání úloh.

Otázka: Mohu přepnout sekundární databázi do režimu čtení i zápisu?

A: Ano, spusťte příkaz RESTORE DATABASE WITH RECOVERY, ale tím se přeruší řetězec odesílání protokolů.

Otázka: Jaké je maximální zpoždění, které mohu nakonfigurovat pro obnovení?

A: Neexistuje žádný pevný limit. Nakonfigurujte zpoždění od minut do dnů na základě vašich požadavků na ochranu.

Otázka: Jak ovlivňuje odesílání protokolů strategii zálohování?

A: Vytváří zálohy transakčních protokolů, které lze použít jak pro odesílání protokolů, tak pro obnovu v daném okamžiku.

Otázka: Mohu pro migraci serveru použít doručování protokolů?

A: Ano, nakonfigurujte odesílání protokolů na nový server, synchronizujte je a poté proveďte plánované přepnutí starého serveru při selhání během údržby.

Otázka: Jaké monitorovací nástroje fungují s přepravou protokolů?

A: SQL Server Management Studio obsahuje vestavěné reporty. Nástroje třetích stran, jako například SQL Monitor a SolarWinds, poskytují vylepšené monitorování.

9. Závěr a doporučení

9.1 Shrnutí klíčových bodů

SQL Server Doprava protokolů (log shipping) poskytuje spolehlivé a cenově efektivní zotavení po havárii prostřednictvím automatizovaného zálohování a obnovy protokolů transakcí. Technologie funguje se Standard Edition, vyžaduje minimální infrastrukturu a podporuje více sekundárních serverů.

Dodávání protokolů vyniká pro středně těžké účely obnovy, kde je přijatelné ruční převzetí služeb při selhání. Mezi klíčová omezení patří požadavek na ruční převzetí služeb při selhání, zpoždění synchronizace a rozsah konfigurace na úrovni databáze.

Technologie se dobře integruje se stávajícími strategiemi zálohování, podporuje vytváření sestav pouze pro čtení v pohotovostním režimu a poskytuje ochranu proti náhodným změnám s odloženou obnovou.

9.2 Správná volba pro vaše prostředí

Před implementací vyhodnoťte doručování protokolů podle vašich specifických požadavků. Zvažte cíle bodů obnovy, cíle doby obnovy, rozpočtová omezení a toleranci provozní složitosti.

Organizace využívající SQL Server Standardní edice s mírnými požadavky na obnovu by měla důrazně zvážit odesílání protokolů. Podniky s přísným RTO pod 15 minut by měly zvážit skupiny dostupnosti Always On.

Zvažte hybridní přístupy kombinující přepravu klád s dalšími technologiemi pro optimalizaci nákladů a zároveň splnění rozmanitých požadavků.

9.3 Další kroky a další zdroje

Začněte s malými pilotními implementacemi, abyste získali zkušenosti. Vypracujte komplexní dokumentaci, včetně podrobností o konfiguraci, postupů pro přepnutí na záložní systém a průvodců řešením problémů.

Naplánujte si pravidelné testy přepnutí na záložní systém, abyste ověřili postupy a udrželi připravenost administrátorů. Udržujte si aktuální informace. SQL Server aktualizace a vylepšení.

Reference

• Oficiální dokument společnosti Microsoft: O přepravě klád (SQL Server)
• Oficiální dokument společnosti Microsoft: Konfigurace odesílání protokolů (SQL Server)

---

O autorovi

Yuan Sheng je seniorní správce databází (DBA) s více než 10 lety zkušeností v SQL Server prostředí a správu podnikových databází. Úspěšně vyřešil stovky scénářů obnovy databází ve finančních službách, zdravotnictví a výrobních organizacích.

Yuan se specializuje na SQL Server obnova databází, řešení pro vysokou dostupnost a optimalizace výkonu. Jeho rozsáhlé praktické zkušenosti zahrnují správu databází o velikosti více terabajtů, implementaci skupin dostupnosti Always On a vývoj automatizovaných strategií zálohování a obnovy pro kritické podnikové systémy.

Díky svým technickým znalostem a praktickému přístupu se Yuan zaměřuje na vytváření komplexních průvodců, které pomáhají správcům databází a IT profesionálům řešit složité SQL Server efektivně zvládá výzvy. Udržuje si přehled o nejnovějších SQL Server vydání a vyvíjející se databázové technologie společnosti Microsoft a pravidelně testuje scénáře obnovy, aby zajistil, že jeho doporučení odrážejí osvědčené postupy z reálného světa.

Máte otázky ohledně SQL Server potřebujete další pokyny k odstraňování problémů s databází? Yuan vítá zpětnou vazbu a návrhy pro vylepšení těchto technických zdrojů.