Back-ups en herstellen
In grote en kleine organisaties kunnen ongelukken en incidenten optreden. Daarom moet u altijd een plan hebben voor het herstellen van uw systemen als er iets misgaat. Als u in SQL Server een database wilt herstellen naar een bepaald tijdstip, is dat alleen mogelijk als u het model voor volledig herstel uitvoert. Bij het herstelmodel met bulksgewijs geregistreerde wijzigingen is het waarschijnlijker dat u de database moet herstellen naar het einde van de back-up van het transactielogboek.
Een van de voordelen van Azure SQL is dat Azure dit allemaal voor u kan doen. Omdat Azure SQL uw back-ups beheert en wordt uitgevoerd in het model voor volledig herstel, kunt u uw database naar elk gewenst moment in de tijd herstellen. U kunt zelfs een verwijderde database herstellen binnen het geconfigureerde retentiebeleid. Uw back-ups worden ook automatisch versleuteld door Microsoft als TDE is ingeschakeld op de logische server of het exemplaar.
Standaard wordt één keer per week een volledige back-up van de database gemaakt. Logboekback-ups worden elke 5-10 minuten gemaakt en er worden elke 12-24 uur differentiële back-ups gemaakt. De back-upbestanden worden standaard opgeslagen in geografisch redundante opslag met leestoegang (RA-GRS) in Azure Storage. U kunt er echter voor kiezen om uw back-ups in zone-redundante opslag (ZRS) of lokaal redundante opslag (LRS) te hebben. Het engineering-team van Azure SQL test automatisch voortdurend het herstellen van geautomatiseerde back-ups van databases die zich bevinden op logische servers en in elastische databasepools. Voor migraties naar Azure SQL Managed Instance wordt een automatische initiële back-up met controlesom van databases teruggezet met de systeemeigen RESTORE-opdracht of de Azure Database Migration Service. Daarnaast kunt u in Azure SQL Managed Instance een systeemeigen alleen-kopiëren back-up maken en deze opslaan in Azure Blob Storage.
Een back-upstrategie maken voor Azure SQL Managed Instance en Azure SQL Database
Azure SQL zorgt voor het zware werk, maar het is nog steeds belangrijk om te begrijpen hoe back-ups worden opgeslagen en verwerkt en wat uw opties zijn voor retentie en herstel. Uiteindelijk bent u nog steeds verantwoordelijk voor de algehele strategie voor herstel naar een bepaald tijdstip, langetermijnretentie en geo-herstel.
Herstel naar een bepaald tijdstip (PITR)
In Azure SQL Database en Azure SQL Managed Instance kunt u een self-service herstel uitvoeren. U kunt het exacte tijdstip selecteren waarnaar u wilt herstellen en het proces starten met behulp van de Azure-portal, de PowerShell/Azure CLI of REST API's. Herstel naar een bepaald tijdstip (PITR) maakt een nieuwe database (met een andere naam) op dezelfde logische server. Als u de oorspronkelijke database wilt vervangen door de naar een bepaald tijdstip herstelde database, moet u de naam van zowel de oorspronkelijke als de nieuwe database wijzigen om weer een werkende database te krijgen. U hoeft geen verbindingsreeksen bij te werken.
De retentie voor herstel naar een bepaald tijdstip varieert van 1 tot 35 dagen. De retentieperiode is (voor alle servicelagen en implementatie-opties) standaard zeven dagen. Bij de meeste implementatie-opties en servicelagen kunt u het beleid instellen op 1 tot 35 dagen, afhankelijk van de vereisten van uw scenario. U hebt bijvoorbeeld slechts één dag nodig voor een testdatabase, maar u kunt het maximum van 35 dagen kiezen voor een essentiële database.
Langetermijnretentie (LTR)
Als 35 dagen niet lang genoeg is om te voldoen aan de behoeften of de nalevingsvereisten van uw organisatie, kunt u kiezen voor langetermijnretentie (LTR). Met deze optie kunt u automatisch volledige databaseback-ups maken die gedurende maximaal 10 jaar zijn opgeslagen in RA-GRS-, ZRS- of LRS-opslag. Voor Azure SQL Database is langetermijnretentie algemeen beschikbaar. Voor Azure SQL Managed Instance is LTR beschikbaar in een beperkte openbare preview.
Geo-herstel
Als er sprake is van een catastrofale gebeurtenis, moet uw organisatie hiervan kunnen herstellen. Uw back-ups worden automatisch opgeslagen in RA-GRS (tenzij u kiest voor ZRS of LRS), wat betekent dat uw back-ups worden opgeslagen in de gekoppelde regio. Zelfs als er een hele regio uitvalt en uw databases of beheerde exemplaren zich in die regio bevinden, bent u beveiligd. U kunt geo-herstel uitvoeren naar een willekeurige andere regio vanuit de meest recente geo-gerepliceerde back-up. Deze back-up kan iets achterlopen op het primaire bestand, omdat het tijd kost om de Azure-blob naar een andere regio te repliceren. U kunt een geo-herstel eenvoudig uitvoeren met behulp van de Azure-portal, PowerShell/Azure CLI of REST API's.