SQL Server Logboekverzending: Complete handleiding voor DBA [2026]

SQL Server Log shipping is een geautomatiseerde oplossing voor noodherstel die warme standby-kopieën van uw productiedatabases onderhoudt. De technologie draagt transactielogbackups over van een primaire database op een primaire serverinstantie naar een of meer secundaire databases op afzonderlijke secundaire serverinstanties. Hierdoor blijven uw secundaire databases gesynchroniseerd met de primaire database, wat bescherming biedt tegen gegevensverlies en serverstoringen.

1.2 Doel en voordelen van houttransport

Log shipping vervult meerdere cruciale functies in databasebeheer:

De belangrijkste functie is noodherstel, waarbij een betrouwbare failover wordt geboden. tarOntvang deze melding wanneer uw primaire server niet beschikbaar is vanwege hardwarestoringen, softwarefouten of catastrofale gebeurtenissen die uw datacenter treffen.
Het is ook acost-effectief oplossing voor hoge beschikbaarheidIn tegenstelling tot bedrijfsfuncties waarvoor dure licenties nodig zijn, werkt log shipping met SQL Server Standaardeditie, waardoor het toegankelijk is voor organisaties met een beperkt budget.
Secundaire databases in standbymodus bieden naast noodherstel ook extra voordelen. Databasebeheerders kunnen ze gebruiken voor alleen-lezen rapportages en zo de querybelasting van de productieserver verminderen.
De functie voor uitgestelde herstel biedt bescherming tegen onbedoelde wijzigingen in de gegevens. Door een herstelvertraging in te stellen, creëert u een tijdsvenster om te herstellen van gebruikersfouten voordat schadelijke wijzigingen uw secundaire database bereiken.

2. SQL Server Logboekverzendingcomponenten en workflow

Houttransport bestaat uit de volgende onderdelen:

Primaire server en primaire database: De primaire server vertegenwoordigt uw productieomgeving. SQL Server instantie waarop de primaire database draait.
Back-up share: De tussenliggende locatie voor het opslaan en overdragen van de back-ups van de transactielogboeken van de primaire server naar de secundaire servers.
Secundaire servers en secundaire databases: De secundaire servers host De warme standby-kopieën van uw primaire database.
Monitorserver (optioneel): Deze server houdt de geschiedenis en status bij van alle back-up-, kopieer- en herstelbewerkingen binnen uw gehele log shipping-topologie.
Agenttaken: Inclusief back-up-, kopieer-, herstel- en waarschuwingstaken, waarmee het volledige logverzendingproces wordt geautomatiseerd.

De automatiseringsworkflow is als volgt:

De back-uptaak wordt uitgevoerd op de primaire server en maakt back-ups van het transactielogboek van de primaire database op de back-upshare.
De kopieertaak wordt uitgevoerd op elke secundaire server en draagt logback-upbestanden over van de back-upshare naar de secundaire server(s).
De herstelprocedure wordt uitgevoerd op elke secundaire server en past gekopieerde transactielogboekback-ups toe op de secundaire database.
De waarschuwingstaak wordt uitgevoerd op de monitoringserver en controleert of back-up- en herstelbewerkingen binnen acceptabele termijnen zijn voltooid.

3. Voorwaarden en vereisten

3.1 SQL Server Versievereisten

Houttransport is beschikbaar sinds SQL Server 2000 en wordt nog steeds ondersteund in alle latere versies vanaf SQL Server Van 2005 tot 2025. Deze langdurige steun toont de stabiliteit en blijvende relevantie van de technologie aan.

3.2 SQL Server Editievereisten

Log shipping werkt met de Standard-, Workgroup-, Enterprise- en Developer-edities van SQL ServerDeze brede ondersteuning voor de editie maakt log shipping toegankelijk voor organisaties zonder Enterprise Edition-licenties, in tegenstelling tot functies zoals Altijd aan-beschikbaarheidsgroepen die Enterprise- of Evaluation-edities vereisen.

Let op: Express Edition ondersteunt geen verzending van logboeken.

3.3 Vereisten voor het databaseherstelmodel

Log shipping vereist dat de primaire database gebruikmaakt van het volledige herstelmodel of het bulk-logged herstelmodel. Het eenvoudige herstelmodel wordt niet ondersteund omdat... SQL Server Het proces verwijdert automatisch transactielogboeken, waardoor de continue logboekketen die nodig is voor logboekverzending wordt verbroken.

Voor meer informatie over herstelmodellen, zie onze uitgebreide gids over SQL Server backup.

4. Logverzending configureren met SSMS

4.1 Map aanmaken voor back-up delen

Voordat u log shipping configureert, dient u de back-upmap voor te bereiden waar de back-ups van het transactielogboek worden opgeslagen en naartoe worden overgebracht.

Maak op de primaire server of een speciale bestandsserver een map aan (bijvoorbeeld: C:\Backup)
Klik met de rechtermuisknop op de map en selecteer Aanbod
Klik op de knop Delen .
Klik op het tabblad Geavanceerd delen
Check Deel deze map
Klik op het tabblad machtigingen en subsidie Volledig beheer toestemming aan de SQL Server serviceaccount NT-service\MSSQLSERVER.
Klik op het tabblad OK toepassen.
Documenteer het netwerkpad (UNC) (bijv. \\SERVER-NAME\Backup)

4.2 Log Shipping inschakelen en configureren

Klik met de rechtermuisknop op de primaire database en selecteer Aanbod.
Zoek in de map Database-eigenschappen dialoogvenster, selecteer het Transactielogboek Verzending pagina in het linkerpaneel.
Check Schakel dit in als primaire database in een log shipping-configuratie. om logboekverzending mogelijk te maken.
Vervolgens kunt u op deze eigenschappenpagina de back-upinstellingen, de secundaire server en de monitoringserver configureren. We zullen deze in de volgende paragrafen toelichten.

4.2.1 Back-upinstellingen configureren

Klik op de knop Back-upinstellingen
Zoek in de map Instellingen voor het back-uppen van het transactielogboek dialoog, onder Netwerkpad naar de back-upmap Voer in dat veld het UNC-pad in (bijvoorbeeld: \\SERVER-NAME\Backup)
Als de back-upmap zich op de primaire server bevindt, voer dan het lokale pad in (bijvoorbeeld: C:\Backup)
Configureer overige instellingen, zoals de bewaartermijn van back-ups, de waarschuwingsdrempel, de back-uptaak en de compressie.
Klik op het tabblad OK Om de instellingen te bevestigen en het dialoogvenster te sluiten.

4.2.2 Secundaire serverinstantie en database configureren

Klik op het tabblad Toevoegen voor Secundaire serverinstanties en databases
Zoek in de map Instellingen voor de secundaire database dialoogvenster, klik Connect om verbinding te maken met de secundaire serverinstantie.
Zoek in de map Secundaire database Selecteer in het dropdownmenu een bestaande database of typ een nieuwe databasenaam in.
Zoek in de map Secundaire database initialiseren tab, selecteer Ja, maak een volledige back-up van de primaire database en herstel deze in de secundaire database (en maak de secundaire database aan als deze nog niet bestaat).
Klik op de knop Bestanden kopiëren .
Zoek in de map Bestemmingsmap voor gekopieerde bestanden (deze map bevindt zich meestal op de secundaire server)Voer het lokale pad van de bestemmingsmap op de secundaire server in.
Zorg ervoor dat de map bestaat en dat de SQL Server Het serviceaccount heeft schrijfrechten.
Klik op het tabblad OK Om de instellingen te bevestigen en het dialoogvenster te sluiten.

4.2.3 Monitor Server configureren

Check Gebruik een monitorserverinstantie.
Klik op het tabblad Instellingen
Klik op het tabblad Connect om verbinding te maken met de monitorserverinstantie
Zet Verwijder de geschiedenis na om de bewaartermijn in uren te specificeren
Klik op het tabblad OK Om de instellingen te bevestigen en het dialoogvenster te sluiten.

4.2.4 Configuratie controleren en voltooien

Controleer alle instellingen op de Transactielogboek Verzending pagina
Controleer de back-upinstellingen, de configuratie van de secundaire server en de bewakingsinstellingen.
Klik op het tabblad OK om de configuratie toe te passen
De wizard maakt alle benodigde taken aan op de primaire, secundaire en monitorservers.
Klik op het tabblad Sluiten wanneer de configuratie voltooid is

5. Voordelen en nadelen van houttransport

5.1 Voordelen van SQL Server Logboekverzending

Cost-Effectieve oplossing: Werkt met SQL Server De standaardeditie elimineert de dure licentievereisten van de Enterprise-editie. Dit maakt betrouwbaar noodherstel toegankelijk voor organisaties met een beperkt budget.
Eenvoudig te configureren en te onderhouden: De configuratiewizard begeleidt beheerders door de installatie met duidelijke opties.ost Databases kunnen binnen 15-30 minuten worden geconfigureerd zonder specialistische training.
Ondersteuning voor meerdere secundaire servers: Ondersteun meerdere secundaire servers zonder architectonische beperkingen. Zet één secundaire server in voor lokaal noodherstel, een andere op afstand en een derde voor rapportage.
Minimale impact op de primaire server: Werkt asynchroon, waardoor de synchronisatiekosten op de primaire server worden geëlimineerd. De transactieverwerkingstijden blijven ongewijzigd.
Maakt gebruik van bestaande back-ups van het transactielogboek: Log shipping-backups zijn standaard transactielogbackups die, onafhankelijk van log shipping, gebruikt kunnen worden voor herstel naar een specifiek tijdstip.
Uitgestelde hersteloptie: De functie voor het uitstellen van het herstel biedt bescherming tegen onbedoelde wijzigingen in de gegevens die niet beschikbaar zijn in realtime replicatieoplossingen.
Geen gedeelde opslagruimte vereist: Maakt gebruik van onafhankelijke opslag op elke server, waardoor gedeelde opslag en de bijbehorende kosten overbodig worden.osts.
Platformoverschrijdende ondersteuning: Werkt identiek op zowel Windows als Linux. SQL Server implementaties.
Werkt domeinoverschrijdend: Vereist geen vertrouwensrelaties tussen domeinen of Active Directory-integratie.

5.2 Nadelen en beperkingen van houttransport

Geen automatische failover: De belangrijkste beperking is de vereiste handmatige failover. Beheerders moeten meerdere stappen uitvoeren voordat de service weer operationeel is.
Vertraging in gegevenssynchronisatie: Secundaire databases lopen qua frequentie van back-ups en herstel altijd achter op primaire databases.
Alleen configuratie op databaseniveau: De configuratie vindt plaats op databaseniveau in plaats van op instantieniveau. Het beschermen van 50 databases vereist 50 afzonderlijke configuraties.
Handmatige wijzigingen in de verbindingsreeks: Applicaties moeten na een failover de verbindingsreeksen bijwerken zodat deze naar de secundaire server verwijzen.
Secundaire database-onderbrekingen: In de standby-modus worden gebruikers via secundaire databases losgekoppeld tijdens herstelbewerkingen.
Gescheiden databasebeheer: Elke databaseconfiguratie moet afzonderlijk worden beheerd, zonder gecoördineerde beheermogelijkheden.

6. Beste werkwijzen en toepassingsvoorbeelden

6.1 Wanneer moet je gebruikmaken van logboekverzending?

Rampenbestrijding met een beperkt budget: Blinkt uit als acost- Effectieve oplossing voor noodherstel voor organisaties die de licentie voor de Enterprise Edition niet kunnen rechtvaardigen.osts.
Matige RPO/RTO-vereisten: Applicaties die 15-30 minuten dataverlies en 30-60 minuten downtime tolereren, sluiten perfect aan op de mogelijkheden van dit apparaat.
Alleen-lezen rapportageserver: Maak alleen-lezen kopieën voor rapportageworkloads die periodieke onderbrekingen van de verbinding tolereren.
Standaardeditie-omgevingen: Organisaties hebben gestandaardiseerd op SQL Server De standaardeditie biedt geen toegang tot Always On Availability Groups, waardoor log shipping de beste beschikbare optie is.
Servermigratieprojecten: Vereenvoudigt servermigraties door tijdens overgangsperioden gesynchroniseerde kopieën te bewaren.
Vertraging in de gegevensverwerking: Configureer herstelvertragingen om databases op vaste punten in het verleden te bewaren voor nalevings- of auditdoeleinden.

6.2 Wanneer u GEEN gebruik moet maken van logboekverzending

Vereisten voor vrijwel geen uitvaltijd: Applicaties met een RTO-vereiste van minder dan 15 minuten kunnen niet vertrouwen op handmatige failover.
Automatische failover vereist: Niet geschikt wanneer bedrijfsvereisten automatische failover zonder tussenkomst van de beheerder vereisen.
Realtime synchronisatie vereist: Applicaties die realtime of bijna realtime data op secundaire servers nodig hebben, kunnen de inherente vertraging van log shipping niet accepteren.
Minimale tolerantie voor gegevensverlies: Organisaties met een RPO die in seconden wordt gemeten of die geen gegevensverlies vereisen, hebben synchrone oplossingen nodig.

6.3 beste praktijken

Optimalisatie van de back-upfrequentie: Breng de frequentie van back-ups in evenwicht met de systeembelasting en de hersteldoelstellingen.tart met tussenpozen van 15 minuten en pas dit aan op basis van de werkelijke behoeften.
Overwegingen met betrekking tot netwerkpaden: Gebruik UNC-paden in plaats van toegewezen schijven voor back-uplocaties. Plaats back-upshares op een betrouwbare netwerkinfrastructuur.
Instellen van monitoring en waarschuwingen: Configureer waarschuwingen voor fouten bij back-up-, kopieer- en hersteltaken direct na het voltooien van de log shipping-configuratie.
Regelmatig testschema: Plan kwartaal- of halfjaarlijkse failover-tests in om procedures te valideren en de paraatheid van de beheerder te waarborgen.
Documentatie Onderhoud: Houd gedetailleerde draaiboeken bij waarin configuratiegegevens, failoverprocedures en stappen voor probleemoplossing zijn gedocumenteerd.
Beveiligingsoverwegingen: Gebruik speciale serviceaccounts met minimale vereiste machtigingen. Beperk de toegang tot netwerkshares op passende wijze.
Schijfruimtebeheer: Bewaak continu de schijfruimte op de back-uplocaties. Configureer waarschuwingen wanneer de beschikbare ruimte onder de 20% komt.
Configuratie van het bewaarbeleid: Stel de bewaartermijn van back-ups in op een langere periode dan de maximaal acceptabele synchronisatievertraging.
Herstelvertraging voor bescherming: Configureer herstelvertragingen wanneer bescherming tegen onbedoelde wijzigingen een langere synchronisatievertraging rechtvaardigt.

7. Problemen oplossen met veelvoorkomende problemen

7.1 Fouten bij back-uptaken

Onvoldoende schijfruimte: Controleer de taakgeschiedenis op fouten met betrekking tot schijfruimte. Controleer de beschikbare en vrije ruimte door oude back-ups te verwijderen of compressie in te schakelen.
Toestemmingsproblemen: Controleer de SQL Server Het serviceaccount heeft volledige beheerrechten voor zowel de lokale map als de netwerkshare.
Database niet volledig hersteld: Schakel terug naar de volledige herstelmodus en maak een volledige back-up naar het herstelpunt.tart de transactielogboekketen.

7.2 Fouten bij het kopiëren

Netwerkpad niet toegankelijk: Test de connectiviteit vanaf de secundaire server door het netwerkpad handmatig in kaart te brengen.
Authenticatieproblemen: Configureer expliciete referenties voor toegang tot netwerkshares als de servers zich in verschillende domeinen bevinden.
Problemen met bestandsvergrendeling: Sluit de back-upmap uit van de realtime scan van het antivirusprogramma om te voorkomen dat bestanden worden vergrendeld.

7.3 Herstel mislukte taken

Ontbrekende back-upbestanden: Controleer of de bestanden in de bestemmingsmap aanwezig zijn en bekijk de kopieergeschiedenis.
Herstelvolgordefout: Identificeer ontbrekende back-ups van transactielogboeken en herstel deze in de juiste volgorde om de logboekketen te repareren.
Database in verkeerde staat: Herstart de log shipping door een volledige back-up terug te zetten met NORECOVERY als iemand de database heeft hersteld.
Beschadiging van databasebestanden: Als het herstelproces ondanks de juiste volgorde en configuratie blijft mislukken, kunnen de databasebestanden zelf beschadigd zijn. In dergelijke gevallen moet u mogelijk een gespecialiseerd hulpmiddel gebruiken. SQL-hersteltool om gegevens uit de beschadigde .MDF- en .NDF-bestanden te extraheren voordat een poging wordt gedaan om log shipping opnieuw te initialiseren.

7.4 Problemen met synchronisatievertraging

Beperkingen van de netwerkbandbreedte: Schakel back-upcompressie in om de bestandsgrootte en de benodigde bandbreedte te verminderen.
Hoog transactievolume: Overweeg om de back-upfrequentie te verhogen om kleinere, beter beheersbare back-upbestanden te creëren.
Onvoldoende herstelfrequentie: Verhoog de frequentie van hersteltaken tot ongeveer dezelfde frequentie als back-ups en minimaliseer de vertraging.

7.5 Problemen met de serververbinding bewaken (SQL 2025)

OLE DB-providerfouten: SQL Server De standaard verplichte encryptie van 2025 conflicteert met oudere versies die geen correcte encryptieconfiguratie hebben.
Versleutelingsconfiguratie komt niet overeen: Controleer de configuratie van de gekoppelde server op de monitorserver en controleer de versleutelingsinstellingen.
Alternatieve oplossingen: Stop en herstart de log shipping met behulp van TLS 1.3-parameters of upgrade alle instanties naar SQL Server 2025.

7.6 SQL Server Problemen met de agentenservice

Service Not StarTed: Controleer de status van de agentservice en configureer deze naar s.tarautomatisch.
Werkschema uitgeschakeld: Controleer de status van de taakplanning en schakel uitgeschakelde planningen in.
Fouten bij de taakstappen: Bekijk de taakgeschiedenis om mislukte stappen en specifieke foutmeldingen te identificeren.

8. Veelgestelde vragen (FAQ)

V: Kan ik logboekverzending gebruiken met Express Edition?

A: Nee, SQL Server Express Edition ondersteunt geen logboekverzending omdat het niet over de volgende functionaliteiten beschikt: SQL Server Middel.

V: Hoe vaak moet ik logbackups inplannen?

A: De standaardintervallen van 15 minuten bieden een redelijke balans. Pas deze aan op basis van uw hersteldoel.

V: Kunnen secundaire databases worden gebruikt voor rapportage?

A: Ja, secundaire databases die in standbymodus zijn geconfigureerd, staan alleen-leestoegang toe tussen herstelbewerkingen.

V: Wat gebeurt er als de primaire server uitvalt?

A: Voer een handmatige failover uit om een secundaire database online te brengen. Het gegevensverlies is gelijk aan de synchronisatievertraging op het moment van de storing.

V: Kan ik meerdere secundaire servers hebben?

A: Ja, log shipping ondersteunt een onbeperkt aantal secundaire servers met onafhankelijke configuraties.

V: Hoe bereken ik de synchronisatievertraging?

A: Vergelijk de tijdstempel van het laatst herstelde transactielogboek met de huidige tijd met behulp van de logboekbewakingstabellen.

V: Kan log shipping werken tussen verschillende domeinen?

A: Ja, het werkt in verschillende domeinen of in werkgroepomgevingen zonder dat er vertrouwensrelaties nodig zijn.

V: Wat is het verschil tussen de modus 'Geen herstel' en de stand-bymodus?

A: Geen enkele herstelmodus houdt de database ontoegankelijk. De standbymodus maakt alleen-lezen query's mogelijk tussen herstelbewerkingen.

V: Kan ik het tempo van de logverzending pauzeren?rarily?

A: Ja, schakel de back-up-, kopieer- en hersteltaken uit om de synchronisatie te pauzeren terwijl de configuratie behouden blijft.

V: Hoe verwijder ik de log shipping-configuratie?

EEN: In de Transactielogboek Verzending eigenschappen pagina:

Haal het vinkje weg Schakel dit in als primaire database in een log shipping-configuratie.
Klik op het tabblad OK Om de configuratie te verwijderen en taken te wissen.

V: Kan ik de secundaire database overschakelen naar de lees-schrijfmodus?

A: Ja, voer RESTORE DATABASE WITH RECOVERY uit, maar dit verbreekt de log shipping-keten.

V: Wat is de maximale vertraging die ik kan instellen voor het herstellen?

A: Er is geen harde limiet. Stel vertragingen in van minuten tot dagen, afhankelijk van uw beveiligingsvereisten.

V: Welke invloed heeft log shipping op de back-upstrategie?

A: Het maakt back-ups van transactielogboeken die bruikbaar zijn voor zowel logboekverzending als herstel naar een specifiek tijdstip.

V: Kan ik log shipping gebruiken voor servermigratie?

A: Ja, configureer log shipping naar de nieuwe server, synchroniseer en voer vervolgens tijdens het onderhoud een geplande failover van de oude server uit.

V: Welke monitoringtools werken met log shipping?

A: SQL Server Management Studio bevat ingebouwde rapportagemogelijkheden. Tools van derden, zoals SQL Monitor en SolarWinds, bieden uitgebreidere monitoring.

9. Conclusie en aanbevelingen

9.1 Samenvatting van de belangrijkste punten

SQL Server Houttransport biedt betrouwbare,ost-Effectief noodherstel dankzij geautomatiseerde back-up- en herstelbewerkingen van transactielogboeken. De technologie werkt met de Standard Edition, vereist minimale infrastructuur en ondersteunt meerdere secundaire servers.

Log shipping is uitermate geschikt voor hersteldoelen met een gemiddelde marge, waarbij handmatige failover acceptabel is. Belangrijke beperkingen zijn onder andere de vereiste van handmatige failover, de synchronisatievertraging en de configuratiemogelijkheden op databaseniveau.

De technologie integreert goed met bestaande back-upstrategieën, ondersteunt alleen-lezen rapportage via de standbymodus en biedt bescherming tegen onbedoelde wijzigingen bij een uitgestelde herstelprocedure.

9.2 De juiste keuze maken voor uw omgeving

Evalueer log shipping aan de hand van uw specifieke vereisten voordat u het implementeert. Houd rekening met herstelpuntdoelstellingen, hersteltijddoelstellingen, budgetbeperkingen en de tolerantie voor operationele complexiteit.

Organisaties die SQL Server Standaardeditie met gemiddelde herstelvereisten zou log shipping sterk moeten overwegen. Organisaties met een strikte RTO van minder dan 15 minuten zouden Always On Availability Groups moeten evalueren.

Overweeg hybride benaderingen die het verzenden van logboeken combineren met andere technologieën voor cost optimalisatie met inachtneming van uiteenlopende eisen.

9.3 Volgende stappen en aanvullende bronnen

Begin met kleinschalige pilotimplementaties om ervaring op te doen. Ontwikkel uitgebreide documentatie, inclusief configuratiegegevens, failoverprocedures en handleidingen voor probleemoplossing.

Plan regelmatig failover-tests in om procedures te valideren en de paraatheid van beheerders te waarborgen. Blijf op de hoogte van de nieuwste ontwikkelingen. SQL Server Updates en verbeteringen.

Referenties

Officieel Microsoft-document: Over houttransport (SQL Server)
Officieel Microsoft-document: Logboekverzending configureren (SQL Server)

Over de auteur

Yuan Sheng is een senior databasebeheerder (DBA) met meer dan 10 jaar ervaring in SQL Server omgevingen en enterprise databasebeheer. Hij heeft honderden databaseherstelscenario's succesvol opgelost in financiële dienstverlening, gezondheidszorg en productiebedrijven.

Yuan is gespecialiseerd in SQL Server Databaseherstel, oplossingen voor hoge beschikbaarheid en prestatieoptimalisatie. Zijn uitgebreide praktijkervaring omvat het beheer van multi-terabyte databases, de implementatie van Always-On Availability Groups en de ontwikkeling van geautomatiseerde back-up- en herstelstrategieën voor bedrijfskritische bedrijfssystemen.

Met zijn technische expertise en praktische aanpak richt Yuan zich op het creëren van uitgebreide handleidingen die databasebeheerders en IT-professionals helpen complexe problemen op te lossen. SQL Server uitdagingen efficiënt. Hij blijft op de hoogte van de nieuwste SQL Server releases en de evoluerende databasetechnologieën van Microsoft, waarbij hij regelmatig herstelscenario's test om ervoor te zorgen dat zijn aanbevelingen overeenkomen met de beste praktijken in de praktijk.

Heb vragen over SQL Server herstel of heeft u aanvullende begeleiding nodig bij het oplossen van databaseproblemen? Yuan verwelkomt feedback en suggesties om deze technische middelen te verbeteren.