Hemsida » hur » Så säkerhetskopierar du SQL-databaser till en nätverksdelning

    Så säkerhetskopierar du SQL-databaser till en nätverksdelning

    Säkerhetskopiering av SQL-databaser är regelbundet. Vi har redan täckt sätt att enkelt kunna säkerhetskopiera alla dina SQL-serverns databaser till en lokal hårddisk, men det skyddar inte mot kör och / eller systemfel. Som ett extra skyddslag mot denna typ av katastrof kan du kopiera eller direkt skapa dina säkerhetskopior på en nätverksdelning.

    Säkerhetskopiera lokalt och kopiera sedan till nätverksdelningen

    Det föredragna och mest direkta sättet att uppnå denna uppgift är helt enkelt att skapa en lokal säkerhetskopia av en databas och sedan kopiera respektive backupfil till en nätverksdelning. Du kan göra detta genom att skapa en batch script som ser ut så här:

    SET LocalFolder = C: Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackup
    SqlCmd -E-Q "Backup Database MyDB till disk ="% LocalFolder% MyDB.bak ""
    XCopy "% LocalFolder% MyDB.bak" "\ 192.168.16.55BackupDatabases" / Z / V
    DEL "% LocalFolder% MyDB.bak"

    Detta skript gör följande (linje för rad):

    1. Ställer in en variabel till den lokala SQL-säkerhetskatalogen.
    2. Skapar en SQL-säkerhetskopiering av MyDB (med Windows-autentisering) till den lokala SQL-säkerhetskatalogen.
    3. Kopierar den lokala backupfilen till en nätverksdelning.
    4. Tar bort den lokala säkerhetskopieringsfilen.

    Återigen är detta den föredragna metoden eftersom den fungerar ur lådan och sannolikheten för att ett backupfel är minimalt eftersom säkerhetskopieringen skapas på en lokal disk. Men om du inte har tillräckligt med diskutrymme för att lagra lokala kopior av säkerhetskopieringsfiler misslyckas den här åtgärden. I så fall måste du lägga till ytterligare diskutrymme eller säkerhetskopiera direkt till en nätverksdelning.

    Säkerhetskopiera direkt till en nätverksdel

    Vanligtvis när du försöker skapa en säkerhetskopia direkt till ett nätverk dela med ett kommando som:

    SqlCmd -E-Q "Backup Database MyDB till disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

    Du kommer mest sannolikt att få ett fel i linje med:

    Msg 3201, Nivå 16, Stat 1, Server JF, Linje 1
    Kan inte öppna backupenhet "\ 192.168.16.55BackupDatabasesMyDB.bak". Operativsystemfel 5 (åtkomst nekas.).
    Msg 3013, Nivå 16, Stat 1, Server JF, Linje 1
    BACKUP DATABASE avslutas onormalt.

    Det här felet uppstår trots att du körde SQL-säkerhetskommandot med hjälp av Windows-autentisering (-E-omkopplaren) och Windows-kontot som möjlighet att komma åt och kopiera filer till delningen via Utforskaren i Windows.

    Anledningen till att denna åtgärd misslyckas är att SQL-kommandot exekveras inom gränserna för kontot som SQL Server-tjänsten körs som. När du tittar på listan Tjänster på datorn ser du sannolikt SQL Server-tjänsten som (kolumnen Logga in som), antingen Lokalt system eller Nätverkstjänst, som är systemkonton som inte har någon nätverksåtkomst.

    I vårt system misslyckas säkerhetskopieringen till ett nätverksdelningskommando eftersom vi har SQL Server-tjänsten som Lokal system, som igen inte kan komma till nätverksresurser.

    För att tillåta SQL att säkerhetskopiera direkt till en nätverksandel måste vi köra SQL Server-tjänsten som ett lokalt konto som har tillgång till nätverksresurser.

    Redigera egenskaperna för SQL Server-tjänsten och på fliken Logga in, konfigurera tjänsten för att köras som ett alternativt konto som har nätverksbehörighet.

    När du klickar på OK får du en uppmaning att inställningarna inte träder i kraft förrän tjänsten startas om.

    Starta om tjänsten igen.

    Tjänsteförteckningen ska nu visa att SQL Server-tjänsten körs som det konto du konfigurerat.

    Nu när du kör kommandot för att säkerhetskopiera direkt till ett nätverk dela:

    SqlCmd -E-Q "Backup Database MyDB till disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

    Du ska se ett framgångsmeddelande:

    Bearbetade 152 sidor för databasen 'MyDB', fil 'MyDB' på fil 1.
    Behandlade 2 sidor för databasen 'MyDB', filen 'MyDB_log' på fil 1.
    BACKUP DATABASE lyckades bearbetas 154 sidor på 0.503 sekunder (2.493 MB / sek).

    Med säkerhetskopieringsfilen nu i nätverksdelningskatalogen:

    Nätverksaktiva överväganden

    Det är viktigt att notera att backupkommandot förväntar sig att det går att ansluta direkt till nätverksdelningen utan att bli uppmanad till behörighetsuppgifter. Kontot du har konfigurerat SQL Server-tjänsten att köra som måste ha en betrodd anslutning till nätverksandelen där respektive behörighetsuppgifter tillåter åtkomst, annars kan ett sådant fel uppstå:

    Msg 3201, Nivå 16, Stat 1, Server JF, Linje 1
    Kan inte öppna backupenhet "\ 192.168.16.55BackupDatabasesMyDB.bak". Operativsystemfel 1326 (Inloggningsfel: Okänt användarnamn eller felaktigt lösenord.).
    Msg 3013, Nivå 16, Stat 1, Server JF, Linje 1
    BACKUP DATABASE avslutas onormalt.

    Det här felet indikerar att kontoens användarnamn och lösenord inte godkändes av nätverksdelningen och kommandot misslyckades.

    Ett annat problem att tänka på är att säkerhetskopieringen utförs direkt till en nätverksresurs, så att eventuella hickningar i nätverksanslutningen kan göra att din backup misslyckas. Av denna anledning bör du bara säkerhetskopiera till nätverksplatser som är stabila (dvs förmodligen inte en VPN).

    Säkerhetsimplikationer

    Som tidigare nämnts föredrar du att använda metoden där du säkerhetskopierar lokalt och sedan kopierar till en nätverksandel eftersom det låter dig köra SQL-tjänsten som ett konto med endast lokal systemåtkomst.

    Genom att köra tjänsten som ett alternativkonto öppnar du dörren för potentiella säkerhetsproblem. Till exempel kan ett skadligt SQL-skript utföra under det alternativa kontot och attackera nätverksresurser. Dessutom kan eventuella ändringar i respektive konto (lösenord ändras / utgå eller radera / inaktivera kontot) orsaka att SQL Server-tjänsten misslyckas att starta.

    Det är viktigt att hålla dessa punkter i åtanke om du kör din SQL Server-förekomst med ett annat konto. Medan dessa inte visas stoppar om lämpliga försiktighetsåtgärder vidtas bör du överväga att lägga till ytterligare hårddiskutrymme och sedan implementera den lokala säkerhetskopian och kopiera så att du kan köra SQL-tjänsten med ett lokalt konto.