Job / Praca

    Windows Server + GPO + LogIN/OFF Script + XCOPY Incremental Backup

    W dużym przedsiębiorstwie zadbanie o backup serwerów i stacji roboczych to dość istotne przedsięwzięcie. Użytkownicy raczej nie są świadomi, że powinni robić kopie tego co ważne. Po czym wnoszę? Po prawie 4 latach pracy jako Admin w dużej korpo, na palcach jednej ręki mogę policzyć osoby które zapytały się, jak lub gdzie mają zgrywać swoje dane lub poprosiły o kupno np dysku USB. Zatem dbamy. Serwery opiszę kiedy indziej – rsync, tar, certyfikaty do ssh, mt – raczej są znane i stosowane, dodatkowo można zastosować bonding do zwiększenia transferu, ale o tym jak już pisałem – kiedy indziej.

    Dzisiaj prosty sposób na użycie polityk Windows Serwera do kopiowania plików użytkowników na zdalny storage w mieszanym środowisku Windows 7 i Windows XP.

    Co to będzie robiło:
    – rozpoznaje jakiego używamy Windowsa :)
    – rozpoznaje czy katalog z nazwą użytkownika jest już stworzony , jeśli nie – tworzy.
    – w katalogach użytkownika dzieli na podkatalogi „dokumenty” i „pulpit” aby nie było bałaganu.
    – wyłącza potwierdzenia kopiowania plików na istniejące pliki
    – kopiuje także pliki ukryte
    – po pierwszym kopiowaniu nadpisuje tylko te które się zmieniły lub dodaje nowe.

    Skrypt BAT wygląda tak:

    IF EXIST %userprofile%\Documents GOTO BackupWin7

    :BackupWinXP

    IF EXIST \\storage\data\%username% GOTO TylkoKopia
    mkdir \\storage\data\%username%
    xcopy /Y "c:\Documents and Settings\%username%\Moje Dokumenty" \\storage\data\%username%\dokumenty /e /i /h /d
    xcopy /Y "c:\Documents and Settings\%username%\Pulpit" \\storage\data\%username%\pulpit /e /i /h /d
    :TylkoKopia
    xcopy /Y "c:\Documents and Settings\%username%\Moje Dokumenty" \\storage\data\%username%\dokumenty /e /i /h /d
    xcopy /Y "c:\Documents and Settings\%username%\Pulpit" \\storage\data\%username%\pulpit /e /i /h /d
    Goto EOF

    :BackupWin7
    IF EXIST \\storage\data\%username% GOTO TylkoKopia7
    mkdir \\storage\data\%username%
    xcopy /Y "c:\Users\%username%\Documents" \\storage\data\%username%\dokumenty /e /i /h /d
    xcopy /Y "c:\Users\%username%\Desktop" \\storage\data\%username%\pulpit /e /i /h /d
    :TylkoKopia7
    xcopy /Y "c:\Users\%username%\Documents" \\storage\data\%username%\dokumenty /e /i /h /d
    xcopy /Y "c:\Users\%username%\Desktop" \\storage\data\%username%\pulpit /e /i /h /d
    Goto EOF

    :EOF

    Zdalna lokalizacja to oczywiście storage – trzeba dopisać swój serwer lub IP gdzie ma się kopiować, lub dopisać do swojego DNS’a IP do maszyny która będzie nazywać się storage.

    /Y – wyłącza promptowanie o potwierdzenie nadpisania pliku
    /D – bez podania czasu działa jak incremental backup

    Pierwszy IF EXIST na podstawie katalogu Documents sprawdza czy używamy Windows XP czy 7. Następnie w odpowiednich blokach IF EXIST sprawdza czy jest na serwerze storage katalog z nazwą użytkownika, jeśli nie ma tworzy ją i zaczyna kopiowanie. Jeśli jest, po prostu zaczyna kopiowanie.

    Skrypt należy zapisać na serwerze w miejscu dla login lub logoff skryptów (odpowiedni katalog otworzy się przy dodawaniu skryptu do GPO).

    W zależności od potrzeb podczepiamy skrypt na logowanie lub wylogowywanie. Przy wylogowywaniu backup następuje zaraz po zakończeniu pracy. Jeśli użytkownik używa komputera stacjonarnego to jest to najlepsza opcja, wyłącza komputer, idzie do domu, komputer kopiuje to co trzeba i się wyłącza. Gorzej jeśli to laptop i użytkownik chce go zabrać i musi czekać, wtedy lepiej dać skrypt jako login. Skrypt odpali się jednocześnie z logowaniem i będzie działał w tle umożliwiając pracę. Można dodać @echo off na początku aby nie było widoczne stado latających plików :)

    Implementacja na Windows Serwer:

    1. gpmc.msc
    2. Wybieramy odpowiednie OU
    3. Prawy klawisz na OU – Create And Link GPO Here…
    4. Nadajemy nazwę
    5. Prawym klawiszem na nazwie
    6. Edit
    7. Wybieramy User Configuration
    8. Wybieramy Windows Settings
    9. Wybieramy Scripts(Login/Logoff)
    10. Dwa razy klikamy na wybranym skrypcie (login lub logoff)
    11. W Logon lub Logoff Properties Wybieramy Add..
    12. Wybieramy Browse.. i wybieramy skrypt do wykonania. (Jeśli go nie ma to właśnie w tej lokalizacji ma się znaleźć – trzeba go tam wkopiować).
    13. OK i zamykamy edycję GPO.
    14. W shellu uaktualniamy polityki – gpupdate /force

    Próbujemy się wylogować lub zalogować, efektem powinny być katalogi użytkowników na zdalnym storageu.

    root@storage:/data/samba# ll
    razem 44
    drwxrwxrwx 10 root root 4096 2012-01-17 14:12 ./
    drwxr-xr-x 7 root root 4096 2012-01-12 21:42 ../
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 13:08 user1/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 13:49 user2/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 12:59 user3/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 13:56 user4/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 14:05 user5/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 13:49 user6/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 13:06 user7/
    drwxr-xr-x 4 nobody nogroup 4096 2012-01-17 14:12 user8/

    Po ciężkim dniu pracy, jeśli storage wyposażony jest w streamer można cały katalog /data/samba nagrać jako gotowy dzienny backup.
    Do skryptu oczywiście można dopisać dodatkowe katalogi w/g potrzeb.
    Raz na jakiś czas (np. miesiąc)warto skasować całą zawartość backupu, aby wykonał się pełen backup, ponieważ skrypt nie kasuje plików które były lokalnie, ale już ich nie ma.

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Job / Praca

    Windows, WSUS, NetBSD i iSCSI

    Wreszcie mogę napisać jakąś techniczną notkę, bo ostatnio coś nie mogłem się zebrać. Zrzucę to na wiosenne przesilenie ;) Dzisiaj będzie nietypowo ponieważ pochwalę Windowsa, a dokładnie rzecz ujmując Windows Server 2003 R2. Prawdę mówiąc nie jestem laikiem jeśli chodzi o Windows, ale dotychczas moje doświadczenie zawodowe było mało związane z Windowsami serwerowymi. Jednak przez całą moją dotychczasową działalność jako admina we wszystkich dżobach gdzieś się tam maszyny z serwerami Windows przewijały. Głównie SBS jako kontroler domeny, albo zwykły do obsługi MSSQL. Obecnie mam pod opieką wspomniany juz w2k3 server na DELL POWEREDGE 1800. Działa na nim Active Directory i wszyscy userzy są do niej podpięci. Zatem pełna kontrola z biurka w rozproszonej lokalizacji. Całkiem przyjemnie się tym zarządza. Ale to jakby tylko narzędzie dzięki któremu można znacznie ułatwić sobie pracę. Prawdziwym powodem dla którego podoba mi się Windows jest WSUS czyli Windows Server Update Service.. W skrócie chodzi o to, że nasz serwer Windowsowy przejmuje rolę witryny Windows Update.

    wsus3-zatwierdzanie.jpg

    Ustalamy jakie aktualizacje nas interesują (są nawet aktualizacje do odtwrzacza Zune jak i wszystkich innych programów MS o których istnieniu nawet nie wiedziałem), języki w których te aktualizacje będą dostępne oraz tworzymy grupy komputerów. Możemy oczywiście wrzucić wszystkie komputery z AD do jednej grupy, ale nasze polityki zakazują takich działań i najpierw poprawki muszą być testowane na maszynach do tego przeznaczonych.

    Kiedy już nasz WSUS zsynchronizuje się z serwerami MS, a trochę to zajmuje czasu (dla poprawek dla Windows XP, 2000, Windows Server, oraz MS SQL i Office’a od 2003 do 2007 w 3 językach WSUS pociągnął 7,2 GB), trzeba tylko zadbać o dystrybucję poprawek. Załatwiamy to jedną polityką w głównym drzewie naszej domeny. Dobrą opcja jest wyłączenie automatycznego restartu komputera, co jest bardzo denerwujące kiedy się akurat nad czymś pracuje. Od tego momentu opcje w klientach dotyczących aktualizacji są wyszarzone co oznacza, że steruje nimi server. Admin ustala tylko które poprawki mają pójść gdzie, które odrzucić itp. i pod koniec dnia wysyła do klientów. Sprawnie, bez ingerencji u pracowników, z raportami co się powiodło a co nie.

    Oczywiście można się spytać, po co to komu? Widzieliście duże biuro z zaktualizowanymi wszystkimi komputerami zostawionymi do dyspozycji użytkowników? Nie ma takich biur. Oprócz tego niedługo zostanie wydany SP3 dla XP (SP1 dla Visty szczęśliwie nas nie dotyczy :), można sobie tylko wyobrazić co się stanie jak kilkaset komputerów zacznie pobierać 200MB w jednym czasie.

    Ok, wystarczy już może o samym Windowsie bo patrząc na tytuł i czytając do tego miejsca pewnie zastanawiacie się gdzie w końcu jest o NetBSD? :) Spokojnie właśnie nadchodzi ten moment. NetBSD również w mojej firmie odgrywa znaczącą rolę, a ilościowo przewyższa nawet maszyny z Windows Serwerem :) Oprócz całej gamy usług, typu groupware, obsługa eventów z Windows czy AS400, IDSa, statystyk, czy inwentaryzacji sprzętu (swoją drogą dzięki Group Policy Object czyli polityk Windowsowych zinwentaryzowanie i to bardzo dogłębne sprzętu i oprogramowania wraz z licencjami można wykonać nie ruszając się z biurka, a dostęp do wyników przez www z bazy mysql w NetBSD ;) NetBSD równierz udostępnia zasoby via Samba. Niestety miejsce na dyskach Windows Servera zaczyna się kończyć dlatego postanowiłem przenieść zawartość WSUS’a na udział Samby. Niestety WSUS nie przewiduje możliwości trzymania swojego content’u na czymś innym niż lokalny dysk z NTFS. Klapa? Nie zupełnie. Tutaj z pomocą również przychodzi NetBSD i obsługa iSCSI. Internet SCSI bo tak brzmi pełna nazwa tej technologii, to obsługa sieciowa dysków ale nie jako udostępnienie udziałów, tylko operacje na urządzeniu blokowym. Dodatkowo dyski można łączyć w jeden wielki wolumen albo stworzyć z kilku RAID. Skoro jest to urządzenie blokowe, klient (a właściwie initiator), może korzystać z serwera (a właściwie target’a) tak jakby korzystał z lokalnego dysku, może go sobie popartycjonować, sformatować itp. Jak więc sprawuje się target NetBSD i initiator Windows? Wyśmienicie się sprawuje! A co najważniejsze konfiguracja całości jest bardzo prosta.

    Ze strony NetBSD nie musimy nic instalować, ponieważ target mamy w base systemie (mowa o 4.0).

    Edytujemy tylko plik /etc/iscsi/target. Mój wygląda tak:

    # extent file or device start length
    extent0 /usr/home/storage/iscsi-wsus 0 100000MB
    # target flags storage netmask
    target0 rw extent0 0.0.0.0/0

    używam pliku o rozmiarze 100GB (rozmiar dynamiczny), initiator ma pełne prawa do tego dysku. Zamiast ścieżki do pliku możemy podać oczywiście całeurządzenia z /dev.

    Ze strony MS, instalujemy oprogramowanie initiatora, wyszukujemy i podłączamy dysk.

    iscsi2a.jpg

    Uaktywanimy go i formatujemy, nadajemy literę dysku.

    iscsi3a.jpg

    W ostatniej zakładce, klikamy BIND ALL aby dysk iSCSI montował się przy starcie systemu.

    iscsi4a.jpg

    Na sam koniec przenosimy zawartość WSUS’a, który już nie protestuje, że nie ma dysku lokalnego z NTFSem ;)

    iscsi6a.jpg

    W logu widać czas, 9 minut dla 7GB danych w dość rozproszonej formie, jeśli dyskiem byłby faktycznie dysk a nie plik czas ten zapewne by się jeszcze skrócił.



    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    Related Posts with Thumbnails
    Add your widget here