Hjemmeside » hvordan » Sådan sikkerhedskopieres SQL-databaser til en netværksdel

    Sådan sikkerhedskopieres SQL-databaser til en netværksdel

    Sikkerhedskopiering af SQL-databaser er regelmæssigt. Vi har allerede dækket måder, der nemt kan sikkerhedskopiere alle dine SQL-serverdatabaser til en lokal harddisk, men det beskytter ikke mod drev og / eller systemfejl. Som et ekstra beskyttelseslag mod denne type katastrofe kan du kopiere eller direkte oprette dine sikkerhedskopier på en netværksandel.

    Backup lokalt og derefter kopiere til netværksdelen

    Den foretrukne og mest direkte måde at udføre denne opgave på er simpelthen at oprette en lokal sikkerhedskopi af en database og derefter kopiere den respektive sikkerhedskopieringsfil til en netværksdeling. Du kan gøre dette ved at oprette et batch script, der ser sådan ud:

    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 script gør følgende (linje for linje):

    1. Sætter en variabel til den lokale SQL backup-mappe.
    2. Opretter en SQL-backup af MyDB (ved hjælp af Windows-godkendelse) til den lokale SQL-backup-mappe.
    3. Kopierer den lokale sikkerhedskopieringsfil til en netværksandel.
    4. Sletter den lokale backupfil.

    Igen er dette den foretrukne metode, fordi den virker ude af kassen, og sandsynligheden for en backupfejl er minimal, da backupen er oprettet på en lokal disk. Men hvis du ikke har tilstrækkelig diskplads til at gemme lokale kopier af backupfiler, vil denne handling mislykkes. I dette tilfælde skal du tilføje ekstra diskplads eller backup direkte til en netværksandel.

    Sikkerhedskopiering direkte til en netværksdel

    Når du forsøger at oprette en sikkerhedskopi direkte til et netværk, skal du typisk bruge en kommando som:

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

    Du vil mest sandsynligt få en fejl i overensstemmelse med:

    Msg 3201, Level 16, State 1, Server JF, Line 1
    Kan ikke åbne backupenhed '\ 192.168.16.55BackupDatabasesMyDB.bak'. Operativsystemfejl 5 (Adgang nægtes.).
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE afsluttes unormalt.

    Denne fejl opstår på trods af at du kørte SQL backup-kommandoen ved hjælp af Windows-godkendelse (-E-switchen) og Windows-kontoen som mulighed for at få adgang til og kopiere filer til delingen via Windows Stifinder.

    Årsagen til, at denne handling mislykkes, er, at SQL-kommandoen udføres inden for grænserne af kontoen, som SQL Server-tjenesten kører som. Når du ser listen Servicer på din computer, vil du sandsynligvis se, at SQL Server-tjenesten kører som (Log On As-kolonnen), enten Lokalt system eller Netværkstjeneste, som er systemkonti, der ikke har adgang til netværk.

    På vores system backupen til en netværks del kommando fejler, fordi vi har SQL Server-tjenesten kører som Local System, som igen ikke kan komme til nogen netværksressourcer.

    For at give SQL mulighed for at sikkerhedskopiere direkte til en netværksandel, skal vi køre SQL Server-tjenesten som en lokal konto, som har adgang til netværksressourcer.

    Rediger egenskaberne for SQL Server-tjenesten og på fanen Log på, konfigurer tjenesten for at køre som en alternativ konto, der har netværksadgangsrettigheder.

    Når du klikker på OK, får du besked om, at indstillingerne først træder i kraft, indtil tjenesten genstartes.

    Genstart tjenesten.

    Servicelisten skal nu vise, at SQL Server-tjenesten kører som den konto, du konfigurerede.

    Nu, når du kører kommandoen for at sikkerhedskopiere direkte til et netværk, del:

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

    Du skal se en succesmeddelelse:

    Behandlet 152 sider til databasen 'MyDB', fil 'MyDB' på fil 1.
    Behandlet 2 sider til database 'MyDB', fil 'MyDB_log' på fil 1.
    BACKUP DATABASE behandles succesfuldt 154 sider på 0,503 sekunder (2.493 MB / sek).

    Med sikkerhedskopieringsfilen nu i netværks delekataloget:

    Network Share Overvejelser

    Det er vigtigt at bemærke, at backupkommandoen forventer at kunne forbinde direkte til netværksandelen uden at blive bedt om at få legitimationsoplysninger. Den konto, du har konfigureret SQL Server-tjenesten til at køre som, skal have en betroet forbindelse med netværksandelen, hvor de respektive legitimationsoplysninger tillader adgang, ellers kan der opstå en fejl:

    Msg 3201, Level 16, State 1, Server JF, Line 1
    Kan ikke åbne backupenhed '\ 192.168.16.55BackupDatabasesMyDB.bak'. Operativsystemfejl 1326 (Logonfejl: ukendt brugernavn eller dårlig adgangskode.).
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE afsluttes unormalt.

    Denne fejl angiver, at kontoens brugernavn og adgangskode ikke blev accepteret af netværksdelingen, og kommandoen mislykkedes.

    Et andet problem at huske på er, at backupen udføres direkte til en netværksressource, så enhver hikke i netværksforbindelsen kan få din backup til at mislykkes. Af denne årsag bør du kun sikkerhedskopiere til netværkssteder, som er stabile (dvs. sandsynligvis ikke en VPN).

    Sikkerhedsimplikationer

    Som tidligere nævnt foretrækkes det at bruge den metode, hvor du sikkerhedskopieres lokalt og derefter kopiere til et netværk, da det giver dig mulighed for at køre SQL-tjenesten som en konto kun med lokal systemadgang.

    Ved at køre tjenesten som en alternativ konto åbner du døren for mulige sikkerhedsproblemer. For eksempel kan et ondsindet SQL-script udføres under den alternative konto og angribe netværksressourcer. Derudover vil eventuelle ændringer i den pågældende konto (ændring af adgangskode / udløb eller sletning / deaktivering af kontoen) medføre, at SQL Server-tjenesten mislykkes i at starte.

    Det er vigtigt at holde disse punkter i tankerne, hvis du kører din SQL Server-forekomst ved hjælp af en alternativ konto. Selvom disse ikke er vist propper, hvis der træffes passende forholdsregler, bør du overveje at tilføje ekstra harddiskplads og derefter implementere den lokale backup og kopi, så du kan køre SQL-tjenesten ved hjælp af en lokal konto.