Główna » jak » Jak wykonać kopię zapasową baz danych SQL do udziału sieciowego

    Jak wykonać kopię zapasową baz danych SQL do udziału sieciowego

    Regularne tworzenie kopii zapasowych baz danych SQL jest obowiązkowe. Omówiliśmy już sposoby na łatwe tworzenie kopii zapasowych wszystkich baz danych SQL Server na lokalnym dysku twardym, ale nie chroni to przed awarią dysku i / lub systemu. Jako dodatkowa warstwa ochrony przed tego typu katastrofą możesz skopiować lub bezpośrednio utworzyć kopie zapasowe w udziale sieciowym.

    Utwórz kopię zapasową lokalnie, a następnie skopiuj do udziału sieciowego

    Preferowanym i najbardziej bezpośrednim sposobem wykonania tego zadania jest po prostu utworzenie lokalnej kopii zapasowej bazy danych, a następnie skopiowanie odpowiedniego pliku kopii zapasowej do udziału sieciowego. Możesz to zrobić, tworząc skrypt wsadowy, który wygląda następująco:

    SET LocalFolder = C: Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackup
    SqlCmd -E -Q "Kopia zapasowa bazy danych MyDB To Disk ="% LocalFolder% MyDB.bak ""
    XCopy "% LocalFolder% MyDB.bak" "\ 192.168.16.55BackupDatabases" / Z / V
    DEL "% LocalFolder% MyDB.bak"

    Ten skrypt wykonuje następujące czynności (linia po linii):

    1. Ustawia zmienną w lokalnym katalogu kopii zapasowych SQL.
    2. Tworzy kopię zapasową SQL MyDB (przy użyciu uwierzytelniania systemu Windows) do lokalnego katalogu kopii zapasowych SQL.
    3. Kopiuje lokalny plik kopii zapasowej do udziału sieciowego.
    4. Usuwa lokalny plik kopii zapasowej.

    Ponownie jest to preferowana metoda, ponieważ działa ona po wyjęciu z pudełka, a prawdopodobieństwo niepowodzenia kopii zapasowej jest minimalne, ponieważ kopia zapasowa jest tworzona na dysku lokalnym. Jeśli jednak nie masz wystarczająco dużo miejsca na dysku, aby przechowywać lokalne kopie plików kopii zapasowych, ta czynność zakończy się niepowodzeniem. W tym przypadku konieczne będzie dodanie dodatkowego miejsca na dysku lub kopii zapasowej bezpośrednio do udziału sieciowego.

    Kopia zapasowa Bezpośrednio do udziału sieciowego

    Zazwyczaj podczas próby utworzenia kopii zapasowej bezpośrednio do udziału sieciowego za pomocą polecenia, takiego jak:

    SqlCmd -E -Q "Baza danych kopii zapasowych MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

    Najprawdopodobniej otrzymasz błąd zgodny z:

    Msg 3201, Level 16, State 1, Server JF, Line 1
    Nie można otworzyć urządzenia kopii zapasowej "\ 192.168.16.55BackupDatabasesMyDB.bak". Błąd systemu operacyjnego 5 (odmowa dostępu)..
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE kończy się nienormalnie.

    Ten błąd występuje pomimo uruchomienia polecenia tworzenia kopii zapasowej SQL przy użyciu uwierzytelniania systemu Windows (przełącznik -E) i konta systemu Windows jako możliwości dostępu do plików i kopiowania ich do udziału za pomocą Eksploratora Windows.

    Przyczyną niepowodzenia tej czynności jest to, że polecenie SQL jest wykonywane w granicach konta, na którym działa usługa SQL Server. Gdy przeglądasz listę usług na swoim komputerze, najprawdopodobniej zobaczysz usługę SQL Server działającą jako (kolumna Log On As) albo System lokalny, albo usługę sieciową, które są kontami systemowymi, które nie mają dostępu do sieci..

    W naszym systemie tworzenie kopii zapasowej do polecenia sieciowego nie powiedzie się, ponieważ usługa SQL Server działa jako system lokalny, który ponownie nie może uzyskać dostępu do żadnych zasobów sieciowych.

    Aby umożliwić tworzenie kopii zapasowych SQL bezpośrednio do udziału sieciowego, musimy uruchomić usługę SQL Server jako konto lokalne, które ma dostęp do zasobów sieciowych.

    Edytuj właściwości usługi SQL Server i na karcie Logowanie, skonfiguruj usługę tak, aby działała jako alternatywne konto z prawami dostępu do sieci.

    Po kliknięciu przycisku OK pojawi się monit, że ustawienia nie zostaną wprowadzone, dopóki usługa nie zostanie ponownie uruchomiona.

    Zrestartuj usługę.

    Lista usług powinna teraz pokazywać, że usługa SQL Server działa jako skonfigurowane konto.

    Teraz po uruchomieniu polecenia tworzenia kopii zapasowej bezpośrednio do udziału sieciowego:

    SqlCmd -E -Q "Baza danych kopii zapasowych MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

    Powinieneś zobaczyć komunikat o powodzeniu:

    Przetworzono 152 strony dla bazy danych "MyDB", plik "MyDB" dla pliku 1.
    Przetworzono 2 strony dla bazy danych "MyDB", plik "MyDB_log" w pliku 1.
    BACKUP DATABASE pomyślnie przetworzyło 154 strony w 0,503 s (2,493 MB / s).

    Z plikiem kopii zapasowej teraz w katalogu udziału sieciowego:

    Uwagi dotyczące udziału sieciowego

    Ważne jest, aby pamiętać, że polecenie tworzenia kopii zapasowej oczekuje, że będzie mogło łączyć się bezpośrednio z udziałem sieciowym bez pytania o dane uwierzytelniające. Konto, na którym skonfigurowano usługę SQL Server do uruchomienia, ponieważ musi mieć zaufane połączenie z udziałem sieciowym, w którym odpowiednie poświadczenia umożliwiają dostęp, w przeciwnym razie może wystąpić następujący błąd:

    Msg 3201, Level 16, State 1, Server JF, Line 1
    Nie można otworzyć urządzenia kopii zapasowej "\ 192.168.16.55BackupDatabasesMyDB.bak". Błąd systemu operacyjnego 1326 (Błąd logowania: nieznana nazwa użytkownika lub nieprawidłowe hasło)..
    Msg 3013, Level 16, State 1, Server JF, Line 1
    BACKUP DATABASE kończy się nienormalnie.

    Ten błąd oznacza, że ​​nazwa użytkownika i hasło konta nie zostały zaakceptowane przez udział sieciowy, a polecenie nie powiodło się.

    Inną kwestią, o której należy pamiętać, jest tworzenie kopii zapasowej bezpośrednio w zasobach sieciowych, więc każda czkawka w połączeniu sieciowym może spowodować awarię kopii zapasowej. Z tego powodu powinieneś tylko wykonywać kopie zapasowe w lokalizacjach sieci, które są stabilne (tj. Prawdopodobnie nie VPN).

    Implikacje bezpieczeństwa

    Jak wspomniano wcześniej, preferowana jest metoda polegająca na tworzeniu kopii zapasowej lokalnie, a następnie kopiowaniu do udziału sieciowego, ponieważ pozwala ona uruchomić usługę SQL jako konto z dostępem tylko do lokalnego systemu..

    Po uruchomieniu usługi jako alternatywnego konta otwierasz drzwi do potencjalnych problemów związanych z bezpieczeństwem. Na przykład złośliwy skrypt SQL może zostać wykonany na alternatywnym koncie i zaatakować zasoby sieciowe. Ponadto wszelkie zmiany na koncie (zmiana / wygaśnięcie hasła lub usunięcie / wyłączenie konta) spowodują, że usługa SQL Server nie uruchomi się.

    Ważne jest, aby pamiętać o tych punktach, jeśli uruchomisz instancję SQL Server przy użyciu alternatywnego konta. Chociaż nie są to stopery show, jeśli zostaną podjęte odpowiednie środki ostrożności, należy rozważyć dodanie dodatkowego miejsca na dysku twardym, a następnie zaimplementować lokalną kopię zapasową i kopię, aby można było uruchomić usługę SQL przy użyciu konta lokalnego.