Hjemmeside » hvordan » Slik sikkerhetskopierer du SQL-databaser til en nettverksdeling

    Slik sikkerhetskopierer du SQL-databaser til en nettverksdeling

    Sikkerhetskopiering av SQL-databaser må være. Vi har allerede dekket måter som enkelt kan sikkerhetskopiere alle SQL-serverdatabasene dine til en lokal harddisk, men dette beskytter ikke mot stasjon og / eller systemfeil. Som et ekstra lag av beskyttelse mot denne typen katastrofe kan du kopiere eller direkte lage sikkerhetskopier på en nettverksandel.

    Sikkerhetskopiering lokalt og deretter Kopier til nettverksdelen

    Den foretrukne og mest direkte måten å oppnå denne oppgaven er, er å bare opprette en lokal sikkerhetskopi av en database og deretter kopiere den respektive sikkerhetskopifilen til en nettverksandel. Du kan gjøre dette ved å lage et batch script som ser slik ut:

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

    Dette skriptet gjør følgende (linje for linje):

    1. Setter en variabel til den lokale SQL-sikkerhetskatalogen.
    2. Oppretter en SQL-sikkerhetskopiering av MyDB (ved hjelp av Windows-godkjenning) til den lokale SQL-sikkerhetskatalogen.
    3. Kopierer den lokale backupfilen til en nettverksandel.
    4. Sletter den lokale backupfilen.

    Igjen, dette er den foretrukne metoden fordi den virker ut av boksen, og sannsynligheten for en backupfeil er minimal siden sikkerhetskopien er opprettet på en lokal disk. Men hvis du ikke har nok diskplass til å lagre lokale kopier av sikkerhetskopifiler, vil denne handlingen mislykkes. I dette tilfellet må du legge til ekstra diskplass eller sikkerhetskopiere direkte til en nettverksandel.

    Sikkerhetskopiering direkte til en nettverksdeling

    Vanligvis, når du prøver å opprette en sikkerhetskopi direkte til et nettverk, deles med en kommando som:

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

    Du vil mest sannsynlig få en feil i tråd med:

    Msg 3201, Nivå 16, Stat 1, Server JF, Linje 1
    Kan ikke åpne backup-enheten '\ 192.168.16.55BackupDatabasesMyDB.bak'. Operativsystemfeil 5 (Tilgang nektes.).
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE avsluttes unormalt.

    Denne feilen oppstår til tross for at du kjørte SQL-sikkerhetskommandoen ved hjelp av Windows-godkjenning (-E-bryteren) og Windows-kontoen som muligheten til å få tilgang til og kopiere filer til delen via Windows Utforsker.

    Årsaken til at denne handlingen mislykkes, er at SQL-kommandoen utføres innenfor grensene til kontoen som SQL Server-tjenesten kjører som. Når du ser listen Tjenester på datamaskinen, ser du sannsynligvis at SQL Server-tjenesten kjører som (Logg på som-kolonnen), enten Lokalt system eller Nettverkstjeneste, som er systemkontoer som ikke har noen nettverkstilgang.

    På vårt system mislykkes backupen til en nettverksandelskommando fordi vi har SQL Server-tjenesten som kjører som Local System, som igjen ikke kan komme til noen nettverksressurser.

    For å tillate SQL å sikkerhetskopiere direkte til en nettverksandel må vi kjøre SQL Server-tjenesten som en lokal konto som har tilgang til nettverksressurser.

    Rediger egenskapene til SQL Server-tjenesten og på Logg på-fanen, konfigurer tjenesten til å kjøre som en alternativ konto som har nettverksrettigheter.

    Når du klikker på OK, får du beskjed om at innstillingene ikke får virkning før tjenesten startes på nytt.

    Start tjenesten på nytt.

    Tjenestelisten bør nå vise at SQL Server-tjenesten kjører som kontoen du har konfigurert.

    Nå når du kjører kommandoen for å sikkerhetskopiere direkte til et nettverk, del:

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

    Du bør se en suksessmelding:

    Behandlet 152 sider for databasen 'MyDB', fil 'MyDB' på fil 1.
    Behandlet 2 sider for databasen 'MyDB', fil 'MyDB_log' på fil 1.
    BACKUP DATABASE vellykket behandlet 154 sider på 0.503 sekunder (2.493 MB / sek).

    Med sikkerhetskopieringsfilen nå i nettverks delekatalogen:

    Nettverksoverskridelser

    Det er viktig å merke seg at sikkerhetskopieringskommandoen forventer å kunne koble direkte til nettverksandelen uten å bli bedt om legitimasjon. Kontoen du har konfigurert SQL Server-tjenesten til å kjøre som må ha en klarert forbindelse med nettverksandelen der de respektive legitimasjonene tillater tilgang, ellers kan det oppstå en feil som dette:

    Msg 3201, Nivå 16, Stat 1, Server JF, Linje 1
    Kan ikke åpne backup-enheten '\ 192.168.16.55BackupDatabasesMyDB.bak'. Operativsystemfeil 1326 (Logonfeil: Ukjent brukernavn eller dårlig passord.).
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE avsluttes unormalt.

    Denne feilen indikerer at kontoens brukernavn og passord ikke ble akseptert av nettverksandelen, og kommandoen mislyktes.

    Et annet problem å huske på er at sikkerhetskopiering utføres direkte til en nettverksressurs, slik at eventuelle hikke i nettverkstilkoblingen kan føre til at backupen din mislykkes. Av denne grunn bør du bare sikkerhetskopiere til nettverkssteder som er stabile (det vil si sannsynligvis ikke en VPN).

    Sikkerhetsimplementer

    Som nevnt tidligere, bruker du metoden der du sikkerhetskopierer lokalt og deretter kopierer til en nettverksandel, da det tillater deg å kjøre SQL-tjenesten som en konto med kun lokal systemtilgang.

    Ved å kjøre tjenesten som en alternativ konto, åpner du døren for potensielle sikkerhetsproblemer. For eksempel kan et skadelig SQL-skript utføres under den alternative kontoen og angripe nettverksressurser. I tillegg vil eventuelle endringer i den respektive kontoen (passord endringer / utløp eller sletting / deaktivering av kontoen) føre til at SQL Server-tjenesten mislykkes i å starte.

    Det er viktig å holde disse punktene i bakhodet hvis du kjører SQL Server-forekomsten din ved hjelp av en alternativ konto. Selv om disse ikke vises, hvis det tas riktige forholdsregler, bør du vurdere å legge til ekstra harddiskplass og deretter implementere den lokale sikkerhetskopien og kopien, slik at du kan kjøre SQL-tjenesten ved hjelp av en lokal konto.