€¦ · Web viewOpis przedmiotu zamówienia. Przedmiotem zamówienia jest: Rozbudowa środowiska kopii zapasowych obecnie eksploatowanego przez Sąd Apelacyjny w Krakowie oraz

ZP.-26-08/18 Załącznik nr 2 do specyfikacji

Opis przedmiotu zamówienia

Przedmiotem zamówienia jest:1. Rozbudowa środowiska kopii zapasowych obecnie eksploatowanego przez Sąd Apelacyjny w

Krakowie oraz przedłużenie wsparcia dla użytkowanych w jego zakresie urządzeń DD2500.2. Modernizacja infrastruktury DataCenter.3. Asysta techniczna inżyniera w wymiarze 500 godzin w okresie 24 miesięcy od dnia podpisania

Protokołu odbioru usługi opisanej w pkt 1 i 2 niniejszego opisu przedmiotu zamówienia.4. Warsztaty szkoleniowe dla 7 administratorów Zamawiającego.

Ad 1. Rozbudowa środowiska kopii zapasowych obecnie eksploatowanego przez Sąd Apelacyjny w Krakowie oraz przedłużenie wsparcia dla użytkowanych w jego zakresie urządzeń DD2500.ZAMAWIAJĄCY posiada i użytkuje środowisko kopii zapasowych na potrzeby DATACENTER, w przypadku którego dane składowane są na dwóch urządzeniach: EMC DD6800 oraz dwóch urządzeniach EMC DD2500 i jednym DD4200. Przedmiotem zamówienia jest rozbudowa oraz modernizacja środowiska eksploatowanego na potrzeby zabezpieczania danych o:

DEDUPLIKATOR umożliwiający BEZPOŚREDNIĄ ASYNCHRONICZNĄ REPLIKACJĘ (umożliwiającą przesyłanie jedynie unikalnych bloków w skali wszystkich zabezpieczanych danych), pomiędzy dwoma obecnie użytkowanymi de-duplikatorami (DD6800), oraz nowym de-duplikatorem - będącym przedmiotem zamówienia. Wraz z urządzeniem powinny zostać dostarczone licencje umożliwiające dwukierunkową replikację w obrębie maksymalnej pojemności urządzenia, licencje powinny umożliwiać wykorzystanie następujących trybów replikacji: Managed File Replication, MTree Replication, Directory Replication, Collection Replication. Oferowany de-duplikator powinien umożliwiać także bezpośredni zapis danych przez eksploatowany obecnie przez Zamawiającego appliance AVAMAR M600, pozostałe szczegółowe wymagania dotyczące de-duplikatora będącego przedmiotem zamówienia przedstawione zostały w dalszej części dokumentu. Wymagane wsparcie na oferowany DEDUPLIKATOR, powinno być realizowane przez producenta w okresie min. 3 lat w trybie 9x5 NBD.

OPROGRAMOWANIE umożliwiające bezpośrednie składowanie danych na oferowanym oraz dotychczas eksploatowanych de-duplikatorach w trybie de-duplikacji na źródle, zarządzanie replikacją aktualnie eksploatowanych de-duplikatorów w trybie Managed File Replication a także wsparcie funkcjonalności Instant Access w przypadku dotychczas eksploatowanych de-duplikatorów, pozostałe szczegółowe wymagania dotyczące oprogramowania będącego przedmiotem zamówienia przedstawione zostały w dalszej części dokumentu.

DEDUPLIKATOR

Lp. Parametr wymagany1. Urządzenie musi być przeznaczone do de-duplikacji i przechowywania kopii zapasowych.

Urządzenie musi spełniać wymagania wyspecyfikowane w niniejszej tabeli.2. Dostarczone urządzenie musi oferować przestrzeń min. 190TB netto (powierzchni użytkowej)

bez uwzględniania mechanizmów protekcji, wymagana skalowalność do min. 280TB netto.

1


3. Dostarczone urządzenie powinno umożliwiać dodatkową rozbudowę o warstwę typu CLOUD dedykowaną dla długotrwałego przechowywania danych (tzw. Long Term Retention) – dane o określonej retencji (zgodnie z założoną polityka retencyjną), bez pośrednictwa dodatkowych urządzeń (typu GATEWAY) powinny zostać przemigrowane (w postaci zdeduplikowanej) na dodatkową warstwę (wymagane wsparcie dla dla AWS lub Microsoft Azure). Wymagana enkrypcja danych przechowywanych na warstwie typu Cloud. Skalowanie wspieranej warstwy typu Cloud powinno stanowić równoważność podwojonej wymaganej maksymalnej pojemności urządzenia (bez uwzględnienia pojemności samego urządzenia)

4. Oferowane urządzenie musi posiadać minimum

4 porty Ethernet 10 Gb/s Base T, 8 portów Ethernet 10 Gb/s Optical.

5. Oferowane urządzenie musi umożliwiać jednoczesny dostęp wszystkimi poniższymi protokołami:

CIFS, NFS Protokołem zapewniającym de-duplikację na źródle VTL

6. Wymagane jest dostarczenie licencji, umożliwiającej dla protokołu NFS de-duplikację na źródle, do pełnej oferowanej pojemności urządzenia

7. Oferowane pojedyncze urządzenie musi osiągać zagregowaną wydajność (dla maksymalnej konfiguracji) protokołami: NFS co najmniej 14 TB/h (dane podawane przez producenta) oraz co najmniej 30 TB/h z wykorzystaniem de-duplikacji na źródle (dane podawane przez producenta).

8. Urządzenie musi pozwalać na jednoczesną obsługę minimum 400 strumieni w tym jednocześnie:

zapis danych minimum 300 strumieniami odczyt danych minimum 50 strumieniami replikacja minimum 50 strumieniami

,pochodzących z różnych aplikacji oraz dowolnych protokołów (CIFS, NFS, VTL, de-duplikacja na źródle) oraz dowolnych interfejsów (FC, LAN) w tym samym czasie.Wymienione wartości 400 jednoczesnych strumieni dla wszystkich protokołów, (czyli jednocześnie 300 dla zapisu i jednocześnie 50 strumieni dla odczytu i jednocześnie 50 strumieni dla replikacji) musi mieścić w przedziale oficjalnie rekomendowanym i wspieranym przez producenta urządzenia.Wszystkie zapisywane strumienie muszą podlegać globalnej de-duplikacji przed zapisem na dysk (in-line) jak opisano w niniejszej specyfikacji.

9. Oferowane urządzenie musi mieć możliwość emulacji następujących bibliotek taśmowych: StorageTek L180,

lub IBM TS 3500.

10. Oferowane urządzenie musi mieć możliwość emulacji napędów taśmowych LTO1, LTO2, LTO3, LTO4, LTO5

11. Urządzenie musi umożliwiać (w przypadku VTL’a) jednoczesną emulację minimum 400 napędów, emulację min. 30 000 slotów w przypadku pojedynczej biblioteki taśmowej oraz emulację sumarycznie min. 60 000 slotów.

12. Oferowane urządzenie musi de-duplikować dane in-line przed zapisem na nośnik dyskowy. Na wewnętrznych dyskach urządzenia nie mogą być zapisywane dane w oryginalnej postaci (niezdeduplikowanej) z jakiegokolwiek fragmentu strumienia danych przychodzącego do

2


urządzenia.13. Technologia de-duplikacji musi wykorzystywać algorytm bazujący na zmiennym,

dynamicznym bloku. Algorytm ten musi samoczynnie i automatycznie dopasowywać się do otrzymywanego strumienia danych, co oznacza, że urządzenie musi dzielić otrzymany pojedynczy strumień danych na bloki o różnej długości, bez konieczności podejmowania czynności mających na celu ustalenie predefiniowanej długości bloków używanych do de-duplikacji danych określonego typu. De-duplikacja zmiennym, dynamicznym blokiem oznacza, że wielkość każdego bloku (na jakie są dzielone dane pojedynczego strumienia backupowego) może być inna niż poprzedniego oraz jest indywidualnie ustalana przez algorytm de-duplikacji zastosowany w urządzeniu. Oferowane urządzenie nie może dzielić jakiegokolwiek pojedynczego strumienia danych backupowych na bloki o ustalonej, tej samej długości.

14. Oferowany produkt musi posiadać obsługę mechanizmów globalnej de-duplikacji dla danych otrzymywanych jednocześnie wszystkimi protokołami (CIFS, NFS, VTL, de-duplikacja na źródle) przechowywanych w obrębie całego urządzenia, co oznacza, że przechowywany na urządzeniu fragment danych nie może być ponownie zapisany bez względu na to, jakim protokołem zostanie ponownie otrzymany. Wszystkie emulowane jednocześnie w obrębie urządzenia biblioteki wirtualne (VTL) oraz udziały NFS/CIFS również powinny podlegać globalnej de-duplikacji – blok danych otrzymany i zapisany w wirtualnej bibliotece „A”, nie może zostać ponownie zapisany, jeśli trafi do innej wirtualnej biblioteki „B” w obrębie tego samego urządzenia (to samo dotyczy udziałów NFS/CIFS). Przestrzeń składowania zdeduplikowanych danych musi być jedna dla wszystkich protokołów dostępowych, co oznacza zastosowanie pojedynczej bazy de-duplikatów bez względu na ilość/rodzaj używanych jednocześnie protokołów dostępowych.

15. Proces de-duplikacji musi odbywać się in-line – w pamięci urządzenia, przed zapisem danych na nośnik dyskowy. Zapisowi na system dyskowy muszą podlegać tylko unikalne bloki danych niezapisane jeszcze na system dyskowy urządzenia. Dotyczy to każdego fragmentu przychodzących do urządzenia danych.

16. Proponowane rozwiązanie nie może w żadnej fazie korzystać (w całości lub częściowo) z bufora na składowanie danych w postaci oryginalnej (niezdeduplikowanej) w celu ich późniejszej de-duplikacji (wymagana de-duplikacja in-line)

17. Wszystkie unikalne bloki przed zapisaniem na dysk muszą być dodatkowo kompresowane18. Oferowane urządzenie musi wspierać (wymagane formalne wsparcie producenta urządzenia),

co najmniej następujące aplikacje backupujące bezpośrednio na oferowane urządzenie: EMC NetWorker, EMC Avamar, Oracle RMAN, Microsoft SQL Server Management Studio, Veeam.W przypadku współpracy z każdą z poniższych aplikacji:

RMAN (dla ORACLE), Microsoft SQL Server Management Studio (dla Microsoft SQL), EMC NetWorker, EMC Avamar, Veeam,

, urządzenie musi umożliwiać de-duplikację na źródle (de-duplikację na zabezpieczanej maszynie) i przesyłanie nowych, nieznajdujących się jeszcze na urządzeniu bloków poprzez sieć LAN.De-duplikacja danych odbywa się na dowolnym serwerze posiadającym funkcjonalność agenta Avamar / serwera RMAN / serwera SQL / klienta systemu NetWorker nieposiadającego licencji Storage Node.De-duplikacja w wyżej wymienionych przypadkach musi zapewniać, aby z serwerów do oferowanego urządzenia były transmitowane poprzez sieć LAN tylko fragmenty danych

3


nieznajdujące się dotychczas na urządzeniu.19. W przypadku przyjmowania backupów z EMC NetWorker, Oracle RMAN, Microsoft MSSQL

(przy wykorzystaniu Microsoft SQL Server Management Studio) Veeam urządzenie musi umożliwiać de-duplikację na źródle (de-duplikację na zabezpieczanej maszynie) i przesłanie nowych, nieznajdujących się jeszcze na urządzeniu bloków poprzez sieć FC.De-duplikacja w wyżej wymienionych przypadkach musi zapewniać, aby z serwerów do urządzenia były transmitowane poprzez sieć FC tylko fragmenty danych nieznajdujące się dotychczas na urządzeniu.

20. W przypadku de-duplikacji na źródle poprzez sieć IP (LAN oraz WAN), wymagana możliwość szyfrowania komunikacji kluczem minimum 256 bitów.

21. Urządzenie powinno umożliwiać zaszyfrowanie przechowywanych danych, wymagane licencje umożliwiające zaszyfrowanie i przechowywanie zaszyfrowanych danych w obrębie maksymalnej pojemności oferowanego urządzenia.

22. Urządzenie musi wspierać de-duplikację na źródle poprzez sieć FC (SAN) minimum dla następujących systemów operacyjnych:

Windows, Linux (RedHat, SuSE), HP-UX, AIX, Solaris.

23. Dla aplikacji EMC NetWorker, urządzenie musi pozwalać na łączenie backupów pełnych i inkrementalnych bez odczytu danych z urządzenia. Zarządzanie łączeniem backupów pełnych i inkrementalnych musi być wykonywane z poziomu aplikacji backup’owej

24. Urządzenie powinno dopuszczać, co najmniej 90% utylizację powierzchni netto, bez widocznego spadku wydajności. Dokumentacja urządzenia nie może wskazywać na jakiekolwiek problemy czy obostrzenia, które mogą pojawić się przy zapełnieniu urządzenia poniżej 90%.

25. Oferowane urządzenie musi umożliwiać bezpośrednią replikację danych do drugiego urządzenia takiego samego typu. Konfiguracja replikacji musi być możliwa w każdym z trybów:

jeden do jednego, wiele do jednego, jeden do wielu, kaskadowej, (urządzenie A replikuje dane do urządzenia B, które te same dane

replikuje do urządzenia C).Replikacja musi się odbywać w trybie asynchronicznym. Transmitowane mogą być tylko te fragmenty danych (bloki), które nie znajdują się na docelowym urządzeniu. Ewentualna licencja na replikację musi być dostarczona w ramach postępowania.

26. Urządzenie musi umożliwiać wydzielenie określonych portów Ethernet dedykowanych do replikacji.

27. W przypadku wykorzystania portów Ethernet do replikacji urządzenie musi umożliwiać przyjmowanie backupów, odtwarzanie danych, przyjmowanie strumienia replikacji, wysyłanie strumienia replikacji tymi samymi portami.

28. Narzut na wydajność związany z replikacją nie może zmniejszyć wydajności urządzenia o więcej niż 10%.

29. Wymagana jest możliwość ograniczenia pasma używanego do replikacji między dwoma urządzeniami – oferowane urządzenie powinno być wyposażone w mechanizm umożliwiający zarządzaniem stopnia wykorzystania pasma na potrzeby replikacji.

4


30. Zdeduplikowane i skompresowane dane przechowywane w obrębie podsystemu dyskowego urządzenia muszą być chronione za pomocą technologii RAID 6.

31. Każda grupa RAID 6 musi mieć przynajmniej 1 dysk hot-spare automatycznie włączany do grupy RAID w przypadku awarii jednego z dysków produkcyjnych. Dyski hot-spare muszą być globalne, możliwe do wykorzystania w innych półkach, w przypadku wyczerpania w nich dysków hot-spare.

32. Oferowane urządzenie musi umożliwiać wykonywanie SnapShot’ów, czyli umożliwiać zamrożenie obrazu danych (stanu backupów) w urządzeniu na określoną chwilę. Oferowane urządzenie musi również umożliwiać odtworzenie danych ze Snapshot’u.Odtworzenie danych ze Snapshot’u nie może wymagać konieczności nadpisania danych produkcyjnych jak również nie może oznaczać przerwy w normalnej pracy urządzenia (przyjmowania/odtwarzania backupów).

33. Urządzenie musi pozwalać na przechowywanie minimum 700 Snapshotów jednocześnie w obrębie oferowanej przestrzeni, przy zachowaniu globalnej de-duplikacji oraz standardowego trybu pracy urządzenia – umożliwiającego wykorzystanie wszystkich dostępnych funkcjonalności.

34. Urządzenie musi umożliwiać podział na logiczne części. Dane znajdujące się w każdej logicznej części muszą być między sobą de-duplikowane (globalna de-duplikacja między logicznymi częściami urządzenia).

35. Urządzenie musi mieć możliwość podziału na minimum 14 logicznych części pracujących równolegle. Producent musi oficjalnie wspierać pracę minimum 14 logicznych części pracujących równolegle z pełną wydajnością urządzenia.

36. Dla każdej z w/w logicznych części oferowanego urządzenia musi być możliwość zdefiniowania oddzielnego użytkownika zarządzającego daną logiczną częścią de-duplikatora. Użytkownicy zarządzający logiczną częścią A muszą widzieć tylko i wyłącznie zasoby logicznej części A i nie mogą widzieć żadnych innych zasobów oferowanego urządzenia.

37. Wymagana możliwość zaprezentowania każdej z logicznych części oferowanego urządzenia, jako niezależnego urządzenia dostępnego za pośrednictwem protokołów:

CIFS, NFS, VTL,

Interfejsu umożliwiającego de-duplikację na źródle38. Urządzenie powinno umożliwiać zdefiniowanie blokady skasowania danych (funkcjonalność

WORM). Blokada skasowania danych musi chronić plik w zdefiniowanym czasie przed usunięciem pliku, modyfikacją pliku.Blokada skasowania danych musi działać w dwóch trybach (do wyboru przez administratora):

1. Możliwość zdjęcia blokady przed upływem ważności danych.

2. Brak możliwości zdjęcia blokady przed upływem ważności danych (COMPLIANCE).

Licencje na blokadę usunięcia/zmiany przechowywanych plików muszą być dostarczone wraz z urządzeniem.

39. Urządzenie musi weryfikować ewentualne przekłamania (zmianę danych) na poziomie: systemu plików

oraz

grup RAID

5


Wymaga się, aby urządzenie weryfikowało sumy kontrolne dla wszystkich fragmentów zapisywanych danych, niezależnie od używanego interfejsu.

40. Urządzenie musi weryfikować dane po zapisie (nie chodzi o ewentualną weryfikację danych indeksowych generowanych przez urządzenie, ale o weryfikację wszystkich zabezpieczanych danych backup’owych). Każda zapisana na dyskach porcja danych musi być odczytana i porównana z danymi otrzymanymi przez urządzenie. Powyższa weryfikacja powinna być realizowana w locie, czyli przed usunięciem z pamięci oryginalnych danych (otrzymanych z aplikacji backupowej), musi być realizowana w trybie ciągłym (a nie ad-hoc), wymagane parametry wydajnościowe urządzenia muszą uwzględniać tę funkcjonalność.Wymagane potwierdzenie opisanej funkcjonalności w oficjalnej dokumentacji producenta oferowanego urządzenia.

41. Urządzenie musi automatycznie (samoczynnie) wykonywać sprawdzanie spójności danych po zapisaniu danych na dysk oraz rozpoznawać i naprawiać błędy w locie.Każde zapisane na fizycznych dyskach dane muszą być odczytane i porównane z danymi otrzymanymi. Proces ten musi odbywać się „w locie” – musi być elementem procesu zapisu danych przez urządzenie.

42. Urządzenie musi automatycznie usuwać przeterminowane dane (bloki danych nienależące do backupów o aktualnej retencji) w procesie czyszczenia.

43. Proces usuwania przeterminowanych danych (czyszczenia) nie może uniemożliwiać pracy procesów backupu / odtwarzania danych (zapisu / odczytu danych z zewnątrz do systemu).

44. Wymagana wbudowana funkcjonalność umożliwiająca zdefiniowanie maksymalnego obciążenia urządzenia procesem usuwania przeterminowanych danych (poziomu obciążenia procesora).

45. Wymagana możliwość zdefiniowania harmonogramu, według którego wykonywany jest proces usuwania przeterminowanych danych (czyszczenia), realizowany równolegle z procesami backup/restore/replication.

46. Standardowa częstotliwość usuwania przeterminowanych danych (czyszczenie) nie powinna być większa niż 1 raz na tydzień - minimalizując czas, w którym backupy/odtworzenia narażone są na spowolnienie (weryfikacja wymagania na podstawie dokumentacji typu DOBRE PRAKTYKI publikowanej przez producenta).

47. Urządzenie musi mieć możliwość zarządzania poprzez Interfejs graficzny dostępny z przeglądarki internetowej, Poprzez linię komend (CLI) dostępną z poziomu ssh (secure shell).

48. Oprogramowanie do zarządzania musi rezydować na oferowanym urządzeniu de-duplikacyjnym.

49. Oferowane urządzenie musi mieć możliwość sprawdzenia pakietu upgrade’ującego firmware urządzenia (GUI lub CLI), to znaczy sprawdzenia czy nowa wersja systemu nie spowoduje problemów z urządzeniem.

50. Urządzenie musi być rozwiązaniem kompletnym, appliancem sprzętowym pochodzącym od jednego producenta. Zamawiający nie dopuszcza stosowania rozwiązań typu gateway. Oferowany typ urządzenia musi być oficjalnie dostępne w ofercie producenta przed ukazaniem się niniejszego postępowania.

51. Rozwiązanie musi być objęte, co najmniej 3 letnim pełnym wsparciem technicznym producenta w zakresie sprzętu i oprogramowania (tj. jednym punktem kontaktu po stronie producenta sprzętu i oprogramowania, dostępem do polskiego zespołu inżynierów wsparcia serwisowego, bezpłatnej dostawy uszkodzonych elementów w terminie do końca następnego

6


dnia roboczego, dostępem do bezpłatnych aktualizacji i poprawek oprogramowania, automatycznego monitoringu systemu i zgłaszania usterek w centralnym systemie serwisowym producenta).

OPROGRAMOWANIE1.

Zamawiający wymaga dostarczenia licencji rozbudowującej obecnie posiadane środowisko kopii zapasowych oparte o serwery EMC Avamar M600 oraz urządzenia składujące dane EMC DataDomain 2500 oraz 4200 wraz z wdrożeniem dla środowiska Data Center (baz danych, maszyn wirtualnych, serwerów plików, serwerów wolnostojących – min. 7 szt.).

2.Wymagane jest dostarczenie wszystkich modułów oprogramowania backupowego tak, aby zapewnić backup całości wyspecyfikowanego środowiska oraz spełnić wszystkie wymienione w niniejszej tabeli funkcjonalności. Wymagane wsparcie na oferowane oprogramowanie realizowane przez producenta w okresie min. 3 lat w trybie 9x5 NBD, gwarantujące dostęp do najnowszych wersji oprogramowania.

3.Wymagane jest dostarczenie licencji oprogramowania backupowego dla środowiska obejmującego zarówno serwery niezwirtualizowane oraz zwirtualizowane, charakteryzującego się sumaryczną ilością fiz. CPU na poziomie 180 szt.

Wymagane jest, aby wszystkie dostępne funkcjonalności oferowanego rozwiązania były odblokowane w ramach oferowanych licencji.

Wymagania dotyczące backupu serwerów (Data Center):

4.Oprogramowanie backupowe musi być w pełni zintegrowane z oferowanym de-duplikatorem a także dotychczas użytkowanymi de-duplikatorami DataDomain 2500 oraz DataDomain 4200, umożliwiać backup zabezpieczanych maszyn na w/w de-duplikatory zarówno poprzez sieć LAN jak również SAN.

5.Wymagana jest możliwość wyboru miejsca de-duplikacji

na źródle, na medium backupowym.

6.Backup z de-deduplikacją na źródle musi być dostępny dla wszystkich typów danych w ramach oferowanego rozwiązania: pliki, bazy danych, obrazy maszyn wirtualnych.

7.Oferowane oprogramowanie musi umożliwiać automatyczne odtwarzanie zmigrowanych przez oferowany oraz obecnie wykorzystywany de-duplikator danych do storage’u obiektowego S3 (w celu długoterminowego przechowywania (LTR)), bez konieczności manualnej interwencji

7


bądź konieczności uruchamiania skryptów. Dane ze storage’u obiektowego powinny zostać ponownie przesunięte do de-duplikatora, aby proces odtwarzania danych z poziomu oferowanej aplikacji backup’owej realizowany był w taki sam sposób w porównaniu z procesem odtwarzania danych cały czas znajdujących się na de-duplikatorze (nie zmigrowanych do storage’u obiektowego). Wymagane oficjalne wsparcie opisanej funkcjonalności.

8.Oprogramowanie backupowe musi zapewniać bezpośredni backup z każdej zabezpieczanej maszyny bezpośrednio na oferowany de-duplikator bez pośrednictwa jakichkolwiek innych serwerów w trybie z de-duplikacją na źródle oraz bez de-duplikacji na źródle - wymagane obie opcje z możliwością dowolnego użycia oraz możliwością przełączania. Powyższa funkcjonalność nie może wymagać dodatkowej licencji poza zwykłą licencja kliencką. Funkcjonalność musi dostępna dla minimum następujących platform: Windows, RedHat, SuSE, HP-UX, Solaris, AIX.

9.Wymagane jest, aby oprogramowanie backupowe zapewniało backup środowiska minimum 10 milionów plików w czasie krótszym niż 30 minut - jako pełny backup (podany wolumen oraz czas backup’u zostały przytoczone dla zobrazowania wymaganej wydajności)

10.Wymagane jest, aby oprogramowanie backupowe zapewniało szybki backup blokowy wielomilionowych systemów plików na maszynach Windows oraz Linux

W trakcie backupu oprogramowanie backupowe musi wykonywać kopie zapasowe fizycznych bloków a nie plików. Wymagana możliwość odtworzenia pojedynczego pliku.

W celu minimalizacji czasu backupu oprogramowanie backupowe nie może indeksować plików znajdujących się na zabezpieczanym wolumenie (zaindeksowanie wielu milionów plików powoduje znaczne wydłużenie czasu backupu).

11.Wymagane jest, aby oprogramowanie backupowe zapewniało szybki inkrementalny backup blokowy wielomilionowych systemów plików na maszynach Windows oraz Linux.

W trakcie backupu inkrementalnego wielomilionowych systemów plików na maszynach Windows oraz Linux oprogramowanie backupowe musi odczytywać tylko te fragmenty dysku, które zmieniły się od ostatniego backupu (wykorzystanie mechanizmu CBT)

Oprogramowanie backupowe nie może odczytywać zmienionych plików, jedynie zmienione bloki na dysku.

W celu minimalizacji czasu backupu oprogramowanie backupowe nie może indeksować plików backupu inkrementalnego znajdujących się na zabezpieczanym wolumenie (zaindeksowanie wielu milionów plików powodowałoby duże wydłużenie czasu backupu).

8


12.Oprogramowanie backupowe musi mieć możliwość łączenia backupu blokowego pełnego i inkrementalnego w jeden pełen backup. Łączenie backupów musi odbywać się na urządzeniu de-duplikacyjnym bez fizycznego odczytu łączonych danych (łączeniu muszą podlegać tylko metadane opisujące backup pełny oraz inkrementalny).

Po połączeniu backupu pełnego i inkrementalnego muszą być dostępne dwa backupy pełne: dotychczas dostępny backup pełny i nowy backup pełny uzyskany w drodze łączenia z backupem inkrementalnym.

13.Wymagana jest możliwość automatycznego łączenia backupu blokowego pełnego i inkrementalnego po wykonaniu blokowego backupu inkrementalnego w celu uzyskania aktualnego backupu pełnego.

14.Oferowane rozwiązanie backupowe musi przechowywać całość własnych informacji (informacje o backupach, napędach taśmowych, mediach) w centralnym pojedynczym katalogu, skopiowanie centralnego katalogu systemu backupu na inną maszynę musi pozwolić na uruchomienie na drugiej maszynie serwera backupu identycznego z oryginalnym. Proces klonowania centralnego katalogu może odbywać się przy wyłączonych procesach backupowych (zapewnienie spójności wewnętrznej bazy danych systemu backupowego).

15.Ze względów bezpieczeństwa rozwiązanie backupowe musi mieć możliwość wykonania kopii wewnętrznej bazy danych w trakcie pracy systemu bez konieczności ograniczania jego funkcjonalności.

16.Oprogramowanie backupowe musi mieć możliwość backupu własnej bazy danych na następujące nośniki:

urządzenie dyskowe, de-duplikator będący przedmiotem zapytania oraz dotychczas eksploatowane de-

duplikatory DD2500 oraz DD4200, nośniki taśmowe.

17.W przypadku backupu na nośniki taśmowe wymagana możliwość zdefiniowania puli taśm (zawierającej jedną lub więcej taśm), na którą będą zapisywane tylko i wyłącznie backupy wewnętrznej bazy danych systemu backupowego.

18.Oprogramowanie backupowe musi mieć możliwość automatycznego wykonywania backupu własnej bazy danych.

19.W przypadku, gdy nie zdefiniowano automatycznego backupu własnej bazy danych oprogramowania backupowego, oprogramowanie backupowe musi samodzielnie minimum

9


raz dziennie backupować własną wewnętrzną bazę danych.

20.Oprogramowanie backupowe po każdorazowym backupie wewnętrznej bazy danych musi raportować poprzez e-mail miejsce, w którym znajduje się ostatni backup wewnętrznej bazy danych oprogramowania backupowego.

21.Backup własnej bazy danych musi pozwalać na odtworzenie wszystkich ustawień systemu backupowego na zupełnie nowej, świeżo zainstalowanej instancji oprogramowania backupowego.

22.Oprogramowanie backupowe musi mieć możliwość (wymagane formalne wsparcie producenta oprogramowania backupowego) działania, jako wirtualna maszyna systemu VMware vSphere.

23.W przypadku backupu systemów produkcyjnych (klientów systemu backupu) na nośniki taśmowe, oferowane oprogramowanie backupowe musi umożliwiać zapisywanie backupów o tym samym terminie ważności na jednej, tej samej, z góry zdefiniowanej puli taśm (zawierającej jedną lub więcej taśm).

24.System musi zapisywać dane na taśmach - zoptymalizowane w sposób eliminujący potrzebę wykonywania dodatkowych działań (nawet automatycznych) w celu ich optymalizacji.

25.W przypadku, gdy w puli taśmowej zabraknie taśm, na których można zapisywać nowe backupy, oprogramowanie backupowe musi mieć możliwość automatycznego przyporządkowania:

wolnych, nieprzyporządkowanych taśm znajdujących się w bibliotece, nieużywanych lub przeterminowanych taśm z innych pul taśmowych.

26.W przypadku użycia biblioteki taśmowej (backup, replikacja z oferowanego oraz wykorzystywanych de-duplikatorów sprzętowych na taśmę), oferowany system musi generować samo-opisujące się taśmy dla całości zapisywanych taśm, co oznacza to, że wyjęcie jakiejkolwiek taśmy z biblioteki i włożenie jej do zupełnie innej biblioteki zarządzanej przez zupełnie inną instancję oferowanego oprogramowania backupowego (w tym również działającą na innym systemie operacyjnym) musi pozwolić na odtworzenie danych znajdujących się na w/w taśmie.

27.Oferowane rozwiązanie musi generować somo-opisujące się zbiory danych zarówno na oferowanym jak i wykorzystywanych de-duplikatorach sprzętowych jak i na taśmach. Utrata wszystkich wewnętrznych danych oprogramowania backupowego nie może powodować braku możliwości odtworzenia jakichkolwiek zbiorów z oferowanego, jaki i obecnie wykorzystywanych de-duplikatorów sprzętowych bądź taśm.

10


28.Oprogramowanie backupowe musi umożliwiać łączenie strumieni backupowych z wielu zabezpieczanych serwerów w sieci LAN i bezpośredni zapis na napędzie taśmowym (multiplexing).

29.Oprogramowanie backupowe musi umożliwiać zarządzanie bezpośrednią replikacją backupów między oferowanym oraz dotychczas eksploatowanymi de-duplikatorami (replikacja realizowana na poziomie deduplikatorów) - bezpośrednio z poziomu interfejsu oprogramowania backupowego przy spełnieniu wszystkich poniższych wymagań

replikacji podlegają tylko te bloki, które nie znajdują się na docelowym de-duplikatorze,

replikacja między de-duplikatorami może nastąpić zarówno bezpośrednio po zakończeniu backupu jak również zgodnie z kalendarzem,

oferowane oprogramowanie backupowe przechowuje informacje o wszystkich kopiach danych znajdujących się na de-duplikatorach m.in. źródłowych jak i po replikacji.

GUI oferowanego oprogramowania backupowego powinien umożliwiać wybór urządzenia de-duplikacyjnego, z którego zostanie wykonane odtwarzanie - w efekcie umożliwiając odtworzenie z oryginalnej kopii backup’owej bądź ze zreplikowanej kopii backup’owej.

30.Oprogramowanie backupowe musi mieć możliwość klonowania backupów między dowolnymi mediami:

de-duplikatorami (obecnie eksploatowanymi oraz będący przedmiotem zapytania), Dyskowymi (CIFS, NFS), Taśmowymi.

31.Oprogramowanie backupowe musi zapewniać różny czas ważności danych na podstawowym nośniku i nośniku zawierającym kopię (replikę backupu). Definicja czasu przechowywania kopii (repliki) powinna być określenia w momencie definiowania zadania duplikacji/klonowania zarówno z interfejsu graficznego jak i z command line.

32.Oprogramowanie backupowe musi mieć możliwość przechowywania informacji o zbackupowanych systemach plików. System backupu przechowuje informację o całym zadaniu backupowym jak również o pojedynczych plikach pozwalając na odtworzenie zarówno całego systemu plików jak również pojedynczego pliku.

33.Oprogramowanie backupowe musi pozwalać na następujące rodzaje backupu systemu plików:

Pełny, Różnicowy, Inkrementalny, Syntetyczny.

11


34.Oprogramowanie backupowe musi pozwalać na łączenie backupów pełnych i inkrementalnych w jeden pełen backup. Proces ten musi być niewidoczny dla systemu plików, którego dotyczą backupy pełne i inkrementalne. Proces odtworzenia danych z połączonego backupu pełnego i inkrementalnego musi być identyczny z odtworzeniem danych z normalnie wykonanego backupu pełnego w zakresie:

Zarządzania, Wydajności.

35.Oprogramowanie backupowe musi pozwalać na łączenie backupów pełnych i inkrementalnych bez odczytu danych z oferowanego urządzenia de-duplikacyjnego.

Łączenie backupów pełnych i inkrementalnych musi odbywać się przez oferowane urządzenie de-duplikacyjne, jedynie zarządzenie (start, kalendarz łączenia) procesem łączenia backupów pełnych i inkrementalnych musi być realizowany przez aplikację backupową.

36.Oprogramowanie backupowe musi pozwalać na zatrzymanie procesu backupu oraz jego wznowienie od momentu zatrzymania.

37.W przypadku nieudanego backupu dla systemu plików (na przykład zerwanie łączności), oprogramowanie backupowe musi pozwalać na wznowienie backupu od ostatnio poprawnie zbackupowanego:

Katalogu, Pliku.

38.W przypadku awarii fragmentu taśmy, oprogramowanie backupowe musi umożliwiać odtworzenie całości plików, które znajdują się na nieuszkodzonej części nośnika.

39.W przypadku konsoli oprogramowania backupowego wymagana jest możliwość definiowania ważności danych (backupów) na podstawie kryteriów czasowych (dni, miesiące, lata). Po okresie ważności backupy musza być automatycznie usunięte.

40.Oprogramowanie backupowe musi wspierać (wymagane wsparcie producenta) następujące systemy operacyjne: Windows (także Microsoft Cluster) , Linux (Red Hat, SUSE, Oracle Linux, CentOS), Solaris, AIX, HP-UX, OpenVMS.

41.Oprogramowanie backupowe musi wspierać (wymagane wsparcie producenta) backup online następujących baz danych i aplikacji: MS Exchange (2010, 2013, 2016), MS SQL, Oracle, IBM DB2, mySQL, Lotus Notes, SharePoint, SAP, Sybase, Informix.

42.W przypadku baz danych system musi umożliwiać inicjalizację backupu poprzez określone zdarzenie: np. ilość logów, czas, który upłynął od ostatniego zdarzenia lub inne zdarzenie

12


zdefiniowane przez użytkownika

43.Dla baz danych MSSQL wymagana jest możliwość inicjowania backupów przez administratora MSSQL przy spełnieniu wszystkich poniższych wymagań:

Backup jest wykonywany przez oferowane oprogramowanie backupowe, Inicjowanie backupu z graficznego interfejsu będącego częścią MSSQL

Management Studio, Możliwość wyboru backupu pełnego, różnicowego oraz logów, Backup inicjowany przez administratora MSSQL nie może wymagać kontaktu z

administratorem oferowanego rozwiązania backupowego.44.

Dla baz danych MSSQL wymagana jest możliwość odtworzenia backupów przez administratora MSSQL przy spełnieniu wszystkich poniższych wymagań:

Odtworzenie dowolnego backupu wykonanego przez oferowane rozwiązanie backupowe,

Zarządzanie odtwarzaniem z graficznego interfejsu będącego częścią MSSQL Management Studio,

Możliwość odtworzenia do dowolnego punktu w czasie wybranego przez administratora MSSQL w ramach przechowywanych przez oferowane oprogramowanie backupowe logów MSSQL,

Odtworzenie bazy danych przez administratora MSSQL nie może wymagać kontaktu z administratorem oferowanego rozwiązania backupowego.

45.Oferowane rozwiązanie backupowe musi integrować się funkcjonalnością FRA (Fast Recovery Area) bazą danych Oracle. Wymagane spełnienie wszystkie poniższych funkcjonalności:

Administrator Oracle wykonuje backupy narzędziami RMAN do przestrzeni FRA,

Oferowane rozwiązanie backupowe automatycznie kopiuje backupy z przestrzeni Oracle FRA na media zarządzane przez oferowane rozwiązanie backupowe,

Definiowanie parametrów zadania kopiowania backupów przestrzeni FRA na media zarządzane przez oferowane rozwiązanie backupowe z poziomu interfejsu graficznego,

Odtworzenie danych możliwe przez administratora Oracle, W procesie odtwarzania, administrator Oracle nie musi wskazywać miejsca,

gdzie znajdują się odtwarzane dane (przestrzeń FRA, media oferowanego rozwiązania backupowego).

46.Oprogramowanie backupowe musi mieć możliwość odtwarzania pojedynczego serwera Windows bez ponownej instalacji systemu operacyjnego.

47.Rozwiązanie backupowe musi mieć możliwość odtworzenia plików na docelową maszynę w oddziale z poziomu centralnej konsoli systemu backupowego. Nie może być wymagane

13


logowanie się na odtwarzaną maszynę w celu odtworzenia danych z systemu backupowego.

48.Wymagana jest możliwość odtworzenia danych:

z zabezpieczanego serwera / komputera, z konsoli systemu backupowego.

Wymagania dotyczące backupu zdalnych lokalizacji oraz środowisk wirtualnych:

49. Oprogramowanie backupowe musi wspierać (wymagane wsparcie producenta) następujące systemy operacyjne: Windows (także Microsoft Cluster) , Linux (Red Hat, SUSE, Debian, CentOS, Ubuntu), Solaris, AIX, HP-UX, Mac OS X, Novell OES, FreeBSD.

Backup zasobów plików w przypadku powyższych systemów musi podlegać de-duplikacji ze zmiennym blokiem na zabezpieczanej maszynie zgodnie z przedstawionymi wymaganiami.

50. Oprogramowanie backupowe musi wspierać (wymagane wsparcie producenta) backup online następujących baz danych i aplikacji: MS Exchange, MS SQL, Oracle, IBM DB2, Lotus Notes, SharePoint, SAP, Sybase, VMware, HyperV.

Backup powyższych baz danych i aplikacji musi podlegać de-duplikacji ze zmiennym blokiem na zabezpieczanej maszynie zgodnie z przedstawionymi wymaganiami.

51. W przypadku zabezpieczania baz danych i aplikacji wymagana możliwość realizacji kopii zapasowej kilkoma strumieniami jednocześnie (minimum 10 jednoczesnych strumieni).

52. Oferowane rozwiązanie musi zabezpieczać zdeduplikowane dane w przypadku systemu Windows 2012 bez konieczności przywracania danych Windows 2012 do postaci oryginalnej (nie zde-duplikowanej).

53. Zabezpieczane serwery muszą być backupowane bezpośrednio na dyski oferowanego jak również wykorzystywanych obecnie de-duplikatorów bez pośrednictwa jakichkolwiek innych urządzeń / serwerów.

Dotyczy to backupów lokalnych, zdalnych jak również backupu laptopów.

54. Oprogramowanie backupowe musi umożliwiać dla sieci lokalnej:

backup pojedynczych plików, backup całych systemów plików, backup baz danych w trakcie ich normalnej pracy, backup ustawień systemu operacyjnego Windows, backup całych obrazów maszyn wirtualnych systemu VMware, backup całych obrazów maszyn wirtualnych systemu Hyper-V.

55. Rozwiązanie backupowe musi umożliwiać transfer danych bezpośrednio ze zdalnych oddziałów do oferowanego de-duplikatora bez konieczności instalacji jakiegokolwiek sprzętu w oddziale. Powyższa funkcjonalność wymagana jest dla następujących typów danych:

14


backup pojedynczych plików, backup całych systemów plików, backup baz danych w trakcie ich normalnej pracy.

56. W przypadku zabezpieczania środowisk zdalnych, oferowane rozwiązanie backupowe nie może wymagać zaangażowania ze strony personelu w oddziale.

57. Wymaga się, aby oferowane rozwiązanie backupowe było w pełni konfigurowalne z konsoli znajdującej się w centrali, w szczególności backupy maszyn w oddziałach (bazy, pliki) czy też backupy laptopów muszą być konfigurowalne z poziomu centralnej konsoli bez konieczności logowania się na zabezpieczaną maszynę.

58. Oferowane rozwiązanie backupowe musi umożliwiać odtworzenie

Plików, baz danych,

, na docelową maszynę w oddziale - z poziomu centralnej konsoli systemu backupowego. Wymagany scenariusz nie może wymagać logowania się na odtwarzaną maszynę celem odtworzenia danych z systemu backupowego.

59. W celu minimalizacji ilości przesyłanych danych, oferowane rozwiązanie musi mieć możliwość przesyłania odtwarzanych danych z medium backupowego do docelowego serwera w postaci skompresowanej, odtwarzane dane powinny zostać rozkompresowane na docelowym serwerze przez agenta oferowanego systemu.

60. Oprogramowanie backupowe musi posiadać funkcjonalność podziału danych (plików, baz danych, obrazów maszyn wirtualnych) na bloki o zmiennej długości. System musi się dopasowywać do struktury dokumentu zapewniając podział na bloki o różnej długości w ramach pojedynczego dokumentu w celu polepszenia efektywności de-duplikacji.

Podział na bloki musi następować bezpośrednio na zabezpieczanym serwerze.

61. Używany algorytm de-duplikacji musi również generować zmienny blok w przypadku backupu pojedynczego dokumentu. Bloki wysyłane w trakcie backupu pojedynczego dokumentu (z zabezpieczanej maszyny do medium de-duplikacyjnego) muszą być różnej długości jednak nie większej niż 32kB.

62. Każdy backupowany dokument w trakcie pojedynczej sesji musi być dzielony na bloki o zmiennej długości nie większej niż 32kB

63. Wymaga się, aby oprogramowanie backupowe przesyłało na obecnie wykorzystywane oraz oferowany de-duplikator tylko unikalne bloki nieznajdujące się na tym urządzeniu, w efekcie skracając czas backupu, obciążenie procesora i zmniejszając ruch w sieci WAN / LAN.

64. Funkcjonalność de-duplikacji nie może wymagać instalacji dodatkowych modułów programowych po stronie klienckiej lub serwera backupowego.

65. Oprogramowanie backupowe nie może odczytywać tych plików z systemu dyskowego, które się nie zmieniły w stosunku do ostatniego backupu. Raz zbackupowany plik nie może być ponownie odczytywany, chyba, że zmieni się jego zawartość.

15


66. Wymaga się, aby oprogramowanie backupowe realizowało wyłącznie logicznie pełne backupy systemu plików. Z zabezpieczanego systemu plików muszą odczytywane tylko nowe lub zmienione pliki, do obecnie wykorzystywanych oraz oferowanego de-duplikatora powinny być przesyłane dane po de-duplikacji, jednak każdy finalny backup musi być logicznie pełnym backupem. W wewnętrznej strukturze systemu musi być przechowywana informacja o każdym backupie i należących do niego danych (blokach), dzięki czemu odtworzenie jakichkolwiek danych plikowych musi być pojedynczym zadaniem identycznym z odtworzeniem danych z pełnego backupu.

67. Wymagana możliwość definiowania w konsoli oprogramowania backupowego ważności (retencji) danych (backupów) na podstawie kryteriów czasowych (dni, miesiące, lata). Po okresie ważności backupy musza być automatycznie usunięte.

68. Wymagana możliwość tworzenia z poziomu GUI (konsoli graficznej) w przypadku oferowanego oprogramowania backupowego, polityk typu Dziadek – ojciec –syn, to znaczy tworzenia polityk, w których zdefiniowano:

Czas przechowywania backupów dziennych, Czas przechowywania backupów tygodniowych, Czas przechowywania backupów miesięcznych, Czas przechowywania backupów rocznych.

69. Oferowane rozwiązanie musi umożliwiać tworzenie wykluczeń, czyli elementów niepodlegających backupowi w ramach zadania backupowego. Wymagana możliwość tworzenia wykluczeń dla dowolnej kombinacji następujących elementów:

wybranych typów plików, np. dla plików z rozszerzeniem mp3, dla całych katalogów (np.: c:\windows), dla pojedynczych plików.

70. Oferowane rozwiązanie musi mieć możliwość zdefiniowania, aby ostatni backup dowolnego zbioru danych nigdy się nie przeterminował. Oznacza to, że jeśli dany zasób nie jest backupowany to automatycznie ostatni ważny backup tego zasobu będzie przechowywany bezterminowo, jedynie administrator może zdecydować o jego usunięciu.

71. Konsola zarządzająca systemem backupowym musi integrować się z Active Directory. Musi być możliwość przydzielania użytkownikom i grupom Active Directory dostępnych ról (min, administrator, monitoring, tylko wykonywanie odtworzeń) w systemie backupowym.

72. Wymagana możliwość generowania (poprzez konsolę) raportów określających zajętość przestrzeni przeznaczonej na składowanie de-duplikatów.

73. Bloki przesyłane z zabezpieczanych serwerów do oferowanego de-duplikatora muszą być kompresowane i szyfrowane algorytmem z kluczem minimum 256-bitowym.

74. Wymagana możliwość szyfrowania danych na medium dyskowym przechowującym backupy (de-duplikaty). Ewentualna licencja szyfrowania nie musi być dostarczona w ramach postępowania.

75. Wymagana jest autentykacja komunikacji między klientem a serwerem backupu (farmą

16


serwerów) oparta na certyfikatach.

76. Oprogramowanie backupowe musi pozwalać na odtwarzanie danych poprzez: wybór odtwarzanych danych, odtworzenie danych w jednym kroku.

77. Wymagana możliwość limitowania wielkości zadania backupowego, jeśli zadanie backupowe przekroczy zdefiniowaną wielkość wówczas nie może być zapisane w systemie backupowym.

78. Oprogramowanie backupowe musi umożliwiać ograniczenie mocy procesora używanej do wykonywania zdania backupu tak, aby odpowiednia moc procesora pozostała do wykorzystania dla innych zadań.

79. Rozwiązanie backupowe musi wspierać backup i odtwarzanie środowisk VMware vSphere 6.0, 6.5

Oprogramowanie backupowe musi umożliwiać w przypadku środowisk VMware następujące typy backupu:

Backup całych maszyn wirtualnych, Backup pojedynczych, wybranych dysków maszyny wirtualnej vmdk, Musi istnieć możliwość zastosowania wyrażeń regularnych do określenia, które

wirtualne dyski VMware mają być backupowane, W trakcie backupu odczytowi z systemu dyskowego mają podlegać tylko zmienione

bloki wirtualnych maszyn systemu VMWare (wymagane wykorzystanie mechanizmu CBT systemu VMWare),

Wykonywanie backupu obrazów maszyn wirtualnych VMware nie może wymagać bufora dyskowego na kopię obrazów maszyn wirtualnych (plików vmdk).

Powyższe metody backupu maszyn wirtualnych muszą podlegać de-duplikacji ze zmiennym blokiem przed wysłaniem danych do medium backupowego zgodnie z wymaganiami dla de-duplikacji powyżej.

Powyższe metody backupu muszą być wbudowane w oferowany system backupu, nie powinny wymagać tworzenia skryptów/dodatkowych komend.

80. Oferowany system musi pozwalać na szybkie odtworzenie

całych obrazów maszyn wirtualnych, pojedynczych dysków maszyny wirtualnej z backupu całej maszyny wirtualnej.

81. Wymaga się, aby oferowane rozwiązanie backupowe umożliwiało odtwarzanie obrazów maszyn wirtualnych VMware z następującymi funkcjonalnościami:

odtwarzanie całych maszyn wirtualnych musi wykorzystywać mechanizm CBT systemu VMware vSphere – odtwarzane są tylko te bloki wirtualnej maszyny/dysku, które uległy zmianie od ostatniego backupu,

odtwarzanie pojedynczych dysków maszyn wirtualnych musi wykorzystywać mechanizm CBT systemu VMware – odtwarzane są tylko te bloki wirtualnej maszyny/dysku, które uległy zmianie od ostatniego backupu,

odtworzenie pojedynczych plików z backupu obrazu maszyny wirtualnej bez konieczności odtworzenia całej maszyny wirtualnej, funkcjonalność ta musi być dostępna dla obrazów maszyn wirtualnych z zainstalowanym systemem operacyjnym

17


Windows oraz Linux, możliwość zamontowania na dowolnym serwerze (fizycznym lub wirtualnym)

zbackupowanych obrazów maszyn wirtualnych Windows (plików vmdk maszyny wirtualnej Windows), w efekcie metoda ta nie odtwarza backupów a jedynie umożliwia na przeglądanie zawartości plików vmdk w backupie z poziomu Eksploratora Plików Windows na dowolnej maszynie.

Powyższe metody odtworzenia muszą być wbudowane w system backupu i w pełni automatyczne nie mogą generować konieczności wykorzystania dodatkowych skryptów/ komend.

82. Oferowane rozwiązanie backupowe musi umożliwiać uruchomienie maszyn wirtualnych bezpośrednio z oferowanego jak i eksploatowanych deduplikatorów DD2500 oraz DD4200 w oparciu o zrealizowany backup, bez konieczności odtwarzania backupu – wymagane oficjalne wsparcie zarówno w przypadku oferowanego jak i obecnie wykorzystywanych de-duplikatorów oraz aplikacji backup’owej.

83. Oferowane oprogramowanie backupowe musi mieć możliwość prezentacji (bez konieczności odtworzenia) zbackupowanych obrazów maszyn wirtualnych VMware (plików vmdk), jako katalogów na maszynie fizycznej w celu ich przeszukiwania (wymagane przeszukiwanie po nazwach plików jak również zawartości plików) z poziomu systemu operacyjnego maszyny fizycznej.

84. Oferowane oprogramowanie backupowe musi mieć możliwość backupu/odtworzenia w trybie „image backup” (backup plików vmdk) maszyn wirtualnych znajdujących się na serwerach VMware ESX bez udziału vCenter.

85. Oferowane oprogramowanie backupowe musi mieć możliwość automatycznego sprawdzania (weryfikacji) zbackupowanych maszyn wirtualnych VMware, wymagana możliwość ustawienia kalendarza weryfikacji maszyn wirtualnych VMware.

Weryfikacja maszyn wirtualnych musi zapewniać minimum:

a. odtworzenie maszyny wirtualnej na zdefiniowanym Data Center/Data Store,b. weryfikację podstawowych procesów,c. możliwość dołączenia własnego skryptu weryfikującego wybrane elementy maszyny

wirtualnej,Wymagana dostępność informacji w konsoli systemu backupu o statusie (poprawna/niepoprawna) weryfikacji maszyny wirtualnej.

86. Administrator (właściciel) danej maszyny wirtualnej VMware musi mieć możliwość samodzielnego (bez konieczności kontaktu z administratorem backupu czy tez administratorem VMware) odtworzenia pojedynczych plików z dowolnego backupu obrazu jego maszyny wirtualnej.

87. Oprogramowanie backupowe musi zawsze przechowywać pełne backupy obrazów maszyn wirtualnych środowiska VMware dla każdej wykonanej w przeszłości kopii zapasowej. Każdy backup obrazu maszyny wirtualnej musi być backupem pełnym.

88. Oferowane rozwiązanie backupowe musi umożliwiać na tworzenie automatycznych polityk backupowych dla:

18


Folderu, Resource Pool,

systemu VMware.

Oznacza to, że dodanie maszyny wirtualnej do folderu, hosta czy resource pooli w systemie VMware spowoduje automatyczne backupowanie dodanej maszyny wirtualnej zgodnie z polityka zdefiniowana dla folderu hosta czy resource pooli w systemie VMware.

89. Rozwiązanie backupowe musi umożliwiać zdefiniowanie polityk backupowych dostępnych dla administratora systemu VMware z poziomu vCenter. Administrator VMware musi mieć możliwość przyporządkowania nowo tworzonych maszyn wirtualnych do polityk backupowych.

90. Oferowany system musi automatycznie naprawiać problemy związane ze snapshotami VMware. W przypadku, gdy system VMware nie usunie snapshotu, oprogramowanie backupowe musi automatycznie ponawiać usunięcie snapshotu a w przypadku konieczności automatycznie konsolidować maszyny wirtualne VMware

91. Wymaga się, aby inicjowanie backupu oraz odtwarzanie maszyn wirtualnych VMware dostępne było z poziomu graficznego interfejsu, linii komend oraz przez REST API

92. Oferowane oprogramowanie backupowe powinno umożliwiać dla środowisk Hyper-V:

backup pojedynczych plików i baz danych z maszyny wirtualnej ze środka maszyny wirtualnej Hyper-V,

backup całych maszyn wirtualnych, (czyli plików vhd reprezentujących wirtualną maszynę), takie wykonanie backupu nie powinno wymagać bufora dyskowego na kopię obrazów maszyn wirtualnych (plików vhd),

wykonywanie backupu jak w poprzezdnim punkcie. powinno umożliwiać na odtworzenie pojedynczych plików z obrazu maszyny wirtualnej bez konieczności odtworzenia całej maszyny wirtualnej, funkcjonalność ta powinna być dostępna dla obrazów maszyn wirtualnych z zainstalowanym systemem operacyjnym Windows.

dopuszcza się wykonywanie snapshotów vss maszyn wirtualnych i użycie ich w trakcie backupu obrazów maszyn wirtualnych.

powyższe metody backupu muszą być wbudowane w system backupu i w pełni automatyczne bez wykorzystania skryptów/dodatkowych komend.

powyższe metody backupu maszyn wirtualnych muszą podlegać de-duplikacji ze zmiennym blokiem w momencie odczytu danych zgodnie z wymaganiami powyżej.

93. Oferowane oprogramowanie backupowe musi zapewniać spójny backup Exchange / MSSQL przy backupie obrazów maszyn wirtualnych środowiska Hyper-V

94. Wymagana możliwość odtworzenia danych

z zabezpieczanego serwera / komputera, z konsoli systemu backupowego.

95. Wymagana możliwość odtworzenia:

19


Pojedynczego pliku, Zabezpieczanej bazy danych.

96. W przypadku systemów Windows 2012, Windows 2016 wymagana funkcjonalność Bare Metal Recovery - automatycznego odtworzenia całego serwera (system operacyjny + ustawienia systemu operacyjnego + dane) w jednym kroku bezpośrednio z oferowanego urządzenia,

Funkcjonalność ta powinna być wbudowana w rozwiązanie backupowe.

97. W przypadku odtwarzania danych poprzez interfejs dostępny na zabezpieczanym serwerze/laptopie wymagany mechanizm autentykacji użytkowników spełniający funkcjonalności:

mechanizm wbudowany w system backupowy, mechanizm zintegrowany z usługami katalogowymi, w przypadku wykorzystania AD, użytkownicy będący w domenie nie muszą się logować

do systemu backupu w przypadku konieczności: odtworzenia danych, przeszukania zwartości swoich backupów, wykonania backupu.

98. W przypadku odtwarzania danych poprzez interfejs końcowego użytkownika dostępnego na zabezpieczanym laptopie/PC wymagane są następujące funkcjonalności:

możliwość wyszukiwania pliku do odtwarzania po nazwie pliku, początkowym fragmencie nazwy pliku, końcowym fragmencie nazwy pliku, fragmencie nazwy pliku umiejscowionym gdziekolwiek w pełnej nazwie pliku,

możliwość przeglądania zawartości zbackupowanego systemu plików i wybór zasobów do odtworzenia,

możliwość wyboru wersji odtwarzanego pliku / katalogu.99. Oferowane rozwiązanie backupowe powinno umożliwiać odtwarzanie plików poprzez

przeglądarkę internetową, odtwarzanie tego typu powinno posiadać następujące funkcjonalności:

uwierzytelnienia użytkownika, możliwość wyszukiwania plików do odtwarzania po:

nazwie pliku, początkowym fragmencie nazwy pliku, końcowym fragmencie nazwy pliku, fragmencie nazwy pliku umiejscowionym gdziekolwiek w pełnej nazwie pliku,

możliwość przeglądania zawartości zbackupowanego systemu plików i wybór zasobów do odtworzenia,

możliwość wyboru wersji odtwarzanego pliku / katalogu.100. W przypadku odtwarzania istniejącego systemu plików (systemu plików, który utracił część

zasobów) oprogramowanie backupowe musi samo, automatycznie sprawdzać, których plików znajdujących się w backupie brakuje na odtwarzanej maszynie a następnie odczytać z backupu i przesłać tylko te pliki, które znajdują się w backupie a których brakuje na odtwarzanej

20


maszynie.

101. Oferowany system backupu musi być dostępny (dla backupu i odtwarzania) przez 24h na dobę 7 dni w tygodniu, wyklucza się istnienie okresów w przypadku, których system backupowy nie może wykonywać backupu lub odtwarzania (tzw. BLACKOUT WINDOWS).

102. Wymaga się, aby oferowany system backupu posiadał możliwość bezpośredniego raportowania o błędach do serwisu producenta

103. Oferowany system backupu powinien mieć możliwość instalacji agentów, jako plików msi. Wymagana możliwość automatyzacji instalacji agentów poprzez uruchomienie skryptu na zabezpieczanej maszynie, przyporządkowującego maszynę automatycznie do określonej polityki backupowej.

104. Oferowany system backupu powinien posiadać możliwość automatycznej samo-aktualizacji poprzez automatyczne ściąganie nowych wersji oprogramowania od producenta.

105. Oferowany system backupu musi mieć możliwość automatycznej aktualizacji oprogramowania agentów wykonywanej bezpośrednio z serwera backupu.

106. Oferowany system musi pozwalać na backup serwerów NAS z następującymi funkcjonalnościami:

w trakcie backupu z systemu NAS muszą być wysyłane do medium backupowego tylko zmienione pliki od ostatniego backupu,

w przypadku odtwarzania danych z backupu, uprawnienia użytkowników również są odtwarzane,

integracja z protokołem NDMP systemów NAS, odtwarzanie plików z backupu NDMP bezpośrednio na platformę Windows/Linux.

W ramach oferowanych licencji wymaga się następujących funkcjonalności – dotyczących monitorowania, raportowania oraz przeszukiwania backupów:

107.W ramach dostarczonych licencji musi być zapewniona możliwość monitorowania, raportowania, szczegółowego rozliczania z użycia komponentów systemu backupowego oraz analizy błędów dla środowiska kopii zapasowej Zamawiającego. Wymagana jest dostępność następujących raportów:

Podsumowanie zadań backupowych (liczba backupów udanych, nieudanych, aktywnych, łączny rozmiar zbackupowanych danych),

Podsumowanie zadań odtworzeniowych (liczba odtworzeń udanych, nieudanych, aktywnych, łączny rozmiar odtworzonych danych danych),

Zbiorcze procentowe zestawienie udanych zadań backupowych z poszczególnych serwerów,

Zbiorcze zestawienie zabezpieczanych serwerów, które w sposób ciągły (kilka razy pod rząd) maja problem z backupami,

Zestawienie zabezpieczanych systemów plików, które w ogóle nie są

21


backupowane, Spodziewany czas odtwarzania zabezpieczanego serwera oraz potencjalnej

utraty danych (czas między ostatnim backupem a chwilą awarii), Najmniej wiarygodne z zabezpieczanych serwerów (procent nieudanych

backupów), Lista najwolniejszych/najszybszych zabezpieczanych maszyn, Poziom SLA (procentowa liczba udanych backupów) w odniesieniu do

poziomu założonego, Mierzenie poziomu SLA dla poszczególnych zabezpieczanych serwerów przy

uwzględnieniu założonego okna backupowego i RPO (punktu, do którego się odtwarzamy),

Liczba danych backupowanych dziennie, Liczba zadań backupowych dziennie, Zużycie zasobów na serwerach backupowych (procesor, pamięć, karty

sieciowe LAN, SAN), Zużycie mediów backupowych i napędów taśmowych, Aktualna konfiguracja systemu backupowego, Historia zmian konfiguracji systemu backupowego, Posiadane licencje systemu backupowego, Wykorzystanie systemu backupowego przez poszczególne działy / grupy

użytkowników (chargeback per cost center).

108. W ramach dostarczonych licencji wymagana możliwość przeszukiwania backupów z poziomu graficznego interface’u (GUI), wymagana możliwość wyszukania dowolnych fraz w nazwach plików.

W ramach oferowanych licencji wymaga się następujących funkcjonalności – dotyczy rozwiązań Continuous Data Protection dla środowisk VMware (min. dla 1000 maszyn wirtualnych).

109. Integracja na poziomie VMware vCenter Plug-in (ORCHESTRATION, MANAGEMENT) , vSphere Web Client GUI

110. Wsparcie dla HA, DRS, S-DRS, VMotion, S-VMotion

111. Możliwość integracji z VMware vRealize Operations Manager

112. Rozwiązanie dostarczane w postaci oprogramowania instalowanego na platformie ESXi

113. Skalowalność zapewniająca wsparcie dla 2000 VM w obrębie poj. vCenter

114. Zabepieczenie dowolnej maszyny wirtualnej wraz z aplikacjami w trybie ciągłym tzn. umożliwiającym odtworzenie do dowolnego punktu w czasie (tzw. PIT – Point In Time), wymagane wsparcie dla VMware ESXi 6.0 oraz 6.5

115. Możliwość tworzenia tzw. CONSISTENCY GROUP zapewniających identyczną konsystencję dla przynależących do danej grupy maszyn wirtualnych (VM)

22


116. Zabezpieczenie realizowane za pośrednictwem ciągłej replikacji (a nie za pomocą SNAPSHOT’ów ) na poziomie VMDK oraz RDM, niezależnie od użytego storage’u (tzw. Storage Agnostic -warunkiem jest wsparcie przez VMware), wymagane wsparcie dla połączeń: FC, FCoE, iSCSI, NAS oraz DAS

117. Wsparcie dla replikacji (bi-directional) asynchronicznej oraz synchronicznej (realizowanej na poziomie dostarczanego oprogramowania), połączonych z mechanizmem tzw. JOURNALING umożliwiającego odnotowanie wszystkich zmian zabezpieczanego środowiska

118. Odporność na krótkotrwałe problemy (przeciążenie, zaniki) związane z siecią WAN

119. Wbudowana funkcjonalność de-duplikacji oraz kompresji w przypadku transmisji danych poprzez WAN

120. Wsparcie dla równoległej replikacji zabezpieczanego środowiska do różnych ośrodków docelowych (min. 3-ech), wsparcie dla replikacji równoległej powinno być zapewnione również na poziomie grup konsystencji (CONSISTENCY GROUP)

121. Proponowane rozwiązanie powinno umożliwiać:

stworzenia DISASTER RECOVERY dla całego zabezpieczanego, wirtualnego środowiska zbudowanego w oparciu o VMware,

operacyjne ODTWARZANIE dowolnej maszyny VM wraz z aplikacjami, MIGRACJI danych w trybie ON-LINE na inne zasoby dyskowe.

122. Równoległe wsparcie środowisk lokalnych oraz zdalnych, wymagana możliwość pracy w 3-ech trybach, tzw.: CDP (Continuous Data Protection - tryb replikacji lokalnej), CRR (Continuous Remote Replication - tryb replikacji zdalnej), CLR (Continuous Local and Remote Replication - połączenie CDP oraz CLR - tryb replikacji lokalnej oraz zdalnej) w ramach dostarczonych licencji

123. Granularność umożliwiająca pominięcie określonych plików VMDK związanych z wirtualnymi serwerami VM objętych protekcją

124. Architektura FAULT-TOLERANT, brak pojedynczego punktu awarii

125. Działanie rozwiązania będącego przedmiotem zapytania nie może mieć ŻADNEGO (!) negatywnego wpływu na wydajność zabezpieczanych maszyn i aplikacji

126. Wyskalowanie systemu powinno gwarantować RPO (Recovery Point Objective) w przypadku codziennej pracy ciągłej na poziomie pojedynczych sekund

127. Proponowana konfiguracja systemu powinna zapewnić następującą retencję przechowywanych kopii bezpieczeństwa:

RPO=30s z ostatnich 24h, RPO=24h z ostatniego tygodnia, RPO=1tydzień z ostatniego miesiąca

23


128. Możliwość odtworzenia zabezpieczanego środowiska do dowolnego punktu w czasie

129. Możliwość trybu pracy umożliwiającego objęciem protekcją w sposób automatyczny nowo dodanych maszyn wirtualnych (VM)

130. Rozwiązanie powinno dopuszczać zmiany HW na poziomie infrastruktury zabezpieczanego środowiska bez negatywnego wpływu na działanie systemu

131. Możliwość użycia mechanizmu typu BOOKMARK dla oznaczenia konsystentnych kopii zabezpieczanych aplikacji

132. Wsparcie dla VSS, zapewnienie konsystencji aplikacji na poziomie VSS

133. Możliwość automatycznego przeprowadzania operacji typu FAILOVER/FAILBACK do dowolnego punktu w czasie dla określonych produkcyjnych serwerów wirtualnych (VM), w tym: odtworzenie, uruchomienie (z zachowaniem wymaganej sekwencji), konfigurację

134. Możliwość automatycznego przeprowadzania operacji typu FAILOVER/FAILBACK do dowolnego punktu w czasie określonych testowych maszyn wirtualnych (VM)

135. Możliwość automatycznego zainicjowania procesu REVERSE REPLICATION w przypadku procesów FAILOVER/FAILBACK

136. Możliwość przeprowadzania testów DR bez wpływu na zabezpieczane serwery produkcyjne oraz bez konieczności zmian w działaniu replikacji (np.: PAUSE, REVERSE, …)

137. Możliwość skryptowego tworzenia planów RECOVERY

W ramach przedłużenia wsparcia dla użytkowanych urządzeń DD2500 wymaga się dostarczenia wsparcia technicznego producenta na urządzenia o numerach seryjnych.

CKM00154900834, CKM00154901646, FLC00144900091, CKM00155000347.

, na okres trzech lat od daty podpisania umowy.

W ramach prac związanych z realizacją zadania, Zamawiający wymaga wykonania:

1.Szczegółowego projektu technicznego instalacji oraz konfiguracji docelowego środowiska w oparciu o zasoby posiadane przez Zamawiającego i dostarczone przez Wykonawcę w ramach niniejszego postępowania wraz z szczegółowym planem jego modernizacji. Wykona również dokumentację powykonawczą (dalej zwaną Dokumentacją rozbudowy)

24


Wykonawca w ramach umowy przeanalizuje wymagania Zamawiającego pod kątem bezpieczeństwa przetwarzanych danych i opracuje Projekt rozbudowy systemu kopii zapasowej (zwany dalej Projektem rozbudowy) w oparciu o zasoby Zamawiającego. Projekt rozbudowy będzie wykonywany przy współpracy z osobami wskazanymi przez Zamawiającego. Wykonawca opracuje (dostarczy) Zamawiającemu Projekt rozbudowy do akceptacji w terminie do …….1od dnia zawarcia Umowy (nie później niż do 20 dni od dnia zawarcia Umowy). Zamawiający w terminie do 2 dni od dnia przekazania Projektu rozbudowy do akceptacji, zgłosi uwagi/zastrzeżenia, a Wykonawca w terminie do 2 dni od dnia przekazania zastrzeżeń dokona korekty w Projekcie rozbudowy.

Projekt rozbudowy Zamawiającego będzie uwzględniał minimum:

a) wykorzystanie obecnie posiadanych urządzeń i licencji,

b) wykorzystanie urządzeń i licencji dostarczanych w ramach niniejszego zamówienia,

c) założenie dwuośrodkowości i związanej z nią niezawodności,

d) wymogów retencyjnych wynikających ze specyfiki eksploatowanych systemów,

e) rekonfigurację obecnego środowiska kopii zapasowych.

f) przeniesienie danych.

Wykonawca na podstawie zaakceptowanego przez Zamawiającego Projektu rozbudowy, w terminie do 20 dni od dnia akceptacji, zainstaluje i skonfiguruje dostarczone urządzenia oraz oprogramowanie, a także sporządzi Dokumentację rozbudowy.

Dokumentacja rozbudowy wymaga akceptacji Zamawiającego. Zamawiający w terminie do 2 dni od dnia przekazania Dokumentacji rozbudowy do akceptacji, zgłosi uwagi/zastrzeżenia, a Wykonawca w terminie do 2 dni od dnia przekazania zastrzeżeń dokona korekty w Dokumentacji rozbudowy.

Wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia muszą charakteryzować się wysoką jakością, na którą będą miały wpływ, takie czynniki jak:

a) struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób.

b) zachowanie standardów, w tym notacji UML, a także sposób pisania, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu.

1 Zapis ten zostanie uzupełniony na podstawie informacji zawartych w Formularzu ofertowym złożonym przez Wykonawcę, którego oferta zostanie uznana za najkorzystniejszą

25


c) kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia.

d) spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

e) wymagane jest aby w ramach Dokumentacji rozbudowy Wykonawca przekazał Zamawiającemu pliki źródłowe zastosowanych w niej obrazów, w tym m.in. schematów, rysunków, topologii oraz wykresów, w formacie niezabezpieczonym i edytowalnym.

Projekt rozbudowy i Dokumentacja rozbudowy, o których mowa powyżej zostaną dostarczone w języku polskim, w wersji elektronicznej w niezabezpieczonym/edytowalnym formacie Word i niezabezpieczonym formacie PDF (na płycie CD/DVD lub innym równoważnym nośniku danych) i drukowanej, co najmniej w 1 egzemplarzu. Wykonawca do Dokumentacji rozbudowy dołączy wykaz zawierający szczegółowy spis Dokumentów wraz z opisem ich przeznaczenia.

Odbiór przedmiotu zamówienia w zakresie dostawy urządzeń i oprogramowania, opracowania Projektu rozbudowy, wykonania prac zgodnie z Projektem rozbudowy, sporządzenia Dokumentacji rozbudowy nastąpi na podstawie podpisanego bez zastrzeżeń przez Strony Protokołu Odbioru Usługi.

2. Rekonfiguracji środowiska kopii zapasowych polegającego na przeniesieniu danych z obecnie wykorzystywanego urządzenia DD4200 na nowe będące przedmiotem postępowania oraz instalacji i konfiguracji urządzeń w lokalizacjach docelowych.

3. Rekonfiguracji środowiska kopii zapasowych polegającego na przeniesieniu danych z obecnie wykorzystywanych urządzeń DD2500 oraz dokonania niezbędnych prac rekonfiguarcyjnych,- instalacji oraz konfiguracji urządzeń DD2500 w lokalizacjach docelowych.

Powyższe prace powinny zostać wykonane bez wpływu na ciągłość działania środowiska kopii zapasowych.

Ad 2. Modernizacja infrastruktury DataCenter.W ramach powyższego zadania Zamawiający wymaga wykonania prac, których efektem będzie rozdzielenie obecnej infrastruktury DataCenter mieszącej się w jednej lokalizacji (zwanej dalej SA) do dwóch ośrodków poprzez przeniesienie jej części do drugiej lokalizacji (zwanej dalej SO). W szczególności zadanie to polegać będzie na:

1. Wykonaniu inwentaryzacji istniejących połączeń kablowych pomiędzy urządzeniami w szafach SA.

2. Wykonanie inwentaryzacji infrastruktury SA oraz SO.3. Opracowaniu topologii fizycznej oraz logicznej obecnej infrastruktury.4. Na podstawie przygotowanej topologii opracowanie koncepcji:

a. rozbudowy sieci LAN i SAN w lokalizacji SO, przy wykorzystaniu posiadanych przez Zamawiającego dwóch przełączników Cisco Nexus 5548UP, wraz z

26


oszacowaniem ilości wymaganych połączeń kablowych i niezbędnych wkładek oraz doborem dodatkowych licencji niezbędnych dla wykonania zadania, jeśli takie będą niezbędne. Wykonawca zapewni dodatkowe elementy, w jakie należy doposażyć infrastrukturę Zamawiającego będące wynikiem wykonanej inwentaryzacji.

b. przeniesienia do lokalizacji SO urządzeń i. Macierzy dyskowej EMC VNX 5300,ii. Węzła klastra SanSymphony DataCore,iii. Serwerów wykorzystujących w/w zasoby.c. przygotowanie listy testów potwierdzających poprawność instalacji i działania.

5. Na podstawie zaakceptowanej przez Zamawiającego koncepcji przygotowanie Projektu modernizacji infrastruktury DataCenter Zamawiającego (dalej zwany „Projektem modernizacji”) obejmującego powyższy zakres i harmonogram prac wraz z listą niezbędnych testów.

6. Przygotowanie oraz wykonanie połączeń logicznych oraz fizycznych z wykorzystaniem posiadanych przez Zamawiającego przełączników Cisco Nexus 5548UP pozwalających na instalację oraz uruchomienie części infrastruktury w lokalizacji SO.

7. Przeniesienie instalacja oraz uruchomienie w/w sprzętu wraz z niezbędnymi testami poprawności działania.

8. Projekt modernizacji wykonywany będzie przy współpracy z osobami wskazanymi przez Zamawiającego. Wykonawca opracuje (dostarczy) Zamawiającemu Projekt modernizacji do akceptacji w terminie do …...2od dnia zawarcia Umowy (nie później niż do 20 dni od dnia zawarcia Umowy). Zamawiający w terminie do 2 dni od dnia przekazania Projektu modernizacji do akceptacji, zgłosi uwagi/zastrzeżenia, a Wykonawca w terminie do 2 dni od dnia przekazania zastrzeżeń dokona korekty w Projekcie modernizacji.

Prace relokacji należy wykonać w sposób niewpływający na ciągłość produkcyjną środowiska Zamawiającego. Lokalizacje dzieli odległość nie większa niż 500 metrów.

9. Wykonawca na podstawie zaakceptowanego przez Zamawiającego Projektu modernizacji w terminie do 20 dni od dnia akceptacji, wykona niezbędne prace, a także sporządzi Dokumentację powykonawczą modernizacji (zwaną dalej Dokumentacją modernizacji). Dokumentacja modernizacji wymaga akceptacji Zamawiającego. Zamawiający w terminie do 2 dni od dnia przekazania Dokumentacji modernizacji do akceptacji, zgłosi uwagi/zastrzeżenia, a Wykonawca w terminie do 2 dni od dnia przekazania zastrzeżeń dokona korekty w Dokumentacji modernizacji.

Ad. 3. Asysta techniczna inżyniera w wymiarze 500 godzin w okresie 24 miesięcy od dnia podpisania Protokołu Odbioru Usługi opisanej w pkt Ad. 1 i 2.

1) Wykonawca zapewni asystę techniczną, zgodnie z potrzebami Zamawiającego, przez minimum jednego inżyniera w okresie 24 miesięcy, licząc od dnia podpisania Protokołu Odbioru Usługi opisanej w pkt Ad. 1 i 2, w wymiarze do 500 roboczogodzin (w roboczogodzinę wsparcia nie wlicza się czasu dojazdu oraz ilości osób świadczących usługę, tzn. nie ma znaczenia ile osób jednocześnie

2 Zapis ten zostanie uzupełniony na podstawie informacji zawartych w Formularzu ofertowym złożonym przez Wykonawcę, którego oferta zostanie uznana za najkorzystniejszą

27


będzie świadczyło usługę w ramach jednej roboczogodziny). Usługa będzie świadczona dla systemu backupowego (sprzętu i oprogramowania), będącego przedmiotem niniejszego zamówienia.

2) Zakres czynności wykonywanych w ramach usługi asysty technicznej nie może być tożsamy z zakresem objętym wsparciem technicznym producenta. W przypadku, gdy Zamawiający zleci Wykonawcy prace, które powinny być zrealizowane w ramach wsparcia technicznego producenta Wykonawca ma obowiązek poinformowania o tym fakcie Zamawiającego.

3) Zlecenia w ramach asysty technicznej będą dotyczyły w szczególności rozwoju i modyfikacji systemu, wsparciu w zakresie utrzymania Systemu.

4) Zamawiający będzie przekazywać Wykonawcy zlecenia, w których każdorazowo określi przedmiot zlecenia oraz określi maksymalny, oczekiwany termin realizacji zlecenia.

5) Wykonawca w terminie wyznaczonym przez Zamawiającego, nie krótszym niż jeden dzień roboczy od otrzymania zlecenia, przekaże Zamawiającemu propozycję wykonania zlecenia zawierającą w szczególności wycenę prac zawartych w zleceniu, proponowaną liczbę roboczogodzin niezbędnych do wykonania zlecenia.

6) Zamawiający może zaakceptować propozycję wykonania zlecenia albo odrzucić propozycję, co jest równoznaczne z nieudzieleniem zlecenia albo zażądać od Wykonawcy, w wyznaczonym terminie, dodatkowych wyjaśnień, informacji do przedstawionej propozycji wykonania zlecenia.

7) W przypadku akceptacji propozycji wykonania zlecenia Zamawiający przedłoży Wykonawcy zaakceptowane zlecenie zawierające w szczególności: zakres prac, liczbę roboczogodzin niezbędną do wykonania prac, kwotę wynagrodzenia należnego za zrealizowanie zlecenia, termin wykonania prac.

8) Rozliczenie wsparcia technicznego inżyniera odbywać się będzie na podstawie podpisanych bez zastrzeżeń, przez Wykonawcę i Zamawiającego, Protokołów odbioru usługi.

9) W ramach godzin wsparcia inżynier na wezwanie Zamawiającego ma obowiązek przybyć do wskazanego miejsca/siedziby na terenie Krakowa, Kielc lub Nowego Sącza i tam realizować zgłoszenie.

10) Świadczenie usługi wsparcia technicznego inżyniera (asysty technicznej) jest jednostronnym uprawnieniem Zamawiającego. Nie skorzystanie przez Zamawiającego z tej usługi lub niewykorzystanie wszystkich przewidzianych w Umowie roboczogodzin nie rodzi po stronie Wykonawcy żadnych roszczeń w stosunku do Zamawiającego.

Ad. 4. Warsztaty szkoleniowe dla 7 administratorów Zamawiającego.

1) Wykonawca przeprowadzi warsztaty szkoleniowe z zakresu merytorycznego dostarczonego oprogramowania dotyczącego zagadnień LTRP. Warsztaty zostaną przeprowadzone w siedzibie Zamawiającego w wymiarze 40 godzin.

2) Wykonawca zobowiązany jest do przeprowadzenia szkoleń w terminie do 30 dni od daty zawarcia Umowy.

3) Każdy uczestnik szkolenia otrzyma certyfikat jego ukończenia.

28


4) Szkolenia muszą być prowadzone w języku polskim.

5) Wykonawca musi dysponować odpowiednio wykwalifikowaną kadrą, której powierzy realizację przedmiotu zamówienia w zakresie szkoleń. Wymagane jest, aby trenerzy posiadali udokumentowane co najmniej 5-cio letnie doświadczenie w przedmiocie szkolenia z zakresu oferowanego rozwiązania.

6) Program warsztatów powinien zawierać informacje dotyczące tematyki prowadzonych warsztatów z podziałem na zajęcia teoretyczne i praktyczne. Program powinien zawierać również informacje dotyczące wiedzy i umiejętności jakie zdobędą uczestnicy po zakończeniu warsztatów. Zamawiający zastrzega sobie prawo do korekty programu warsztatów w zakresie nieograniczonym regulacjami prawnymi.

8) Wykonawca, w uzgodnieniu z Zamawiającym, przygotuje szczegółowe harmonogramy – z rozpisaniem na dni i godziny - oraz programy warsztatów i dostarczy je do 7 dni roboczych przed realizacją zamówienia do akceptacji przez Zamawiającego. Zamawiający zastrzega sobie możliwość korekty przedstawionych dokumentów. Harmonogram zajęć powinien zawierać informacje dotyczące czasu i miejsca realizacji danego warsztatu.

9) Zajęcia powinny odbywać się w dni powszednie od poniedziałku do piątku, w godzinach od 7:30 do 15.30, nie więcej niż 8 godzin dziennie. Harmonogram powinien zostać wydrukowany i rozdany uczestnikom szkolenia na pierwszym spotkaniu.

10) Wykonawca przygotuje i zapewni materiały szkoleniowe dla każdego uczestnika szkolenia, pozwalające na samodzielną edukację z zakresu tematyki szkoleń (opracowania, wydruku materiałów szkoleniowych).

11) Komplet materiałów szkoleniowych dla każdego uczestnika szkolenia obejmuje:

a) papierową wersję materiałów szkoleniowych. Zamawiający dopuszcza dostarczenie materiałów w formie elektronicznej, np. dokumenty w standardzie PDF, w miejsce materiałów papierowych;

b) materiały papiernicze (notatnik, długopis) i inne środki dydaktyczne niezbędne do realizacji szkolenia.

12) Komplet materiałów powinien zostać rozdany uczestnikom szkolenia w pierwszym dniu zajęć.

14) Wykonawca zapewni:

a) ciepły posiłek, w formie zestawu obiadowego (zupa, drugie danie, napój), dla każdego uczestnika szkolenia, we wszystkie dni szkolenia, podczas przerwy obiadowej;

b) miejsce posiłku nie powinno być oddalone dalej niż 10 minut drogi pieszo od miejsca szkolenia;

c) obiady powinny być zróżnicowane, dany zestaw obiadowy nie powinien powtarzać się częściej niż raz na 5 dni szkoleniowych;

d) dwie przerwy pomiędzy zajęciami;

e) w ramach każdej z dwóch przerw kawowych należy zapewnić dla każdego uczestnika szkolenia kawę, herbatę, cukier, mleczko do kawy, wodę mineralną gazowana, niegazowaną;

29


f) czas na przerwy kawowe i obiadowe należy doliczyć do założonej liczby godzin

dydaktycznych szkolenia.

15) Koszty posiłków ponosi Wykonawca.

16) Potwierdzeniem prawidłowej realizacji warsztatów będzie podpisany bez zastrzeżeń przez Zamawiającego Protokół odbioru warsztatu wraz z dołączonymi załącznikami tj. oryginalną listą obecności, harmonogramem i programem warsztatu oraz ankiety oceny warsztatu przeprowadzonej wśród uczestników warsztatu.

Informacje dodatkowe1. Wykonawca w ramach realizacji przedmiotu zamówienia zobowiązany jest do dostarczenia wszystkich

elementów i licencji niezbędnych do jego wykonania. Wszystkie dokumenty powinny być sporządzone w języku polskim, a jeżeli nie są dostępne to w języku angielskim.

2. Wszystkie licencje muszą zostać dostarczone Zamawiającemu ze wszystkimi składnikami niezbędnymi do potwierdzenia legalności ich pochodzenia (np.: certyfikat autentyczności, kod aktywacyjny wraz z instrukcją aktywacji, wpis na stronie producenta oprogramowania itp.).

3. Wykonawca oświadcza, że posiada niczym nieograniczone prawa do udzielenia lub zapewnienia udzielenia na rzecz Zamawiającego licencji na oprogramowanie.

4. Dostarczone urządzenia muszą być nowe (tj. muszą być wyprodukowane nie wcześniej niż 6 miesięcy przed ich dostawą), wolne od wad, fabrycznie nowe - bez śladów używania i bez uszkodzeń, wprowadzone na rynek zgodnie z przepisami obowiązującymi na terenie Rzeczypospolitej Polskiej. Urządzenia muszą być dostarczone Zamawiającemu w oryginalnych opakowaniach fabrycznych, zabezpieczających przed uszkodzeniem w trakcie transportu i składowania, z załączonymi kartami gwarancyjnymi, dokumentami producenckimi i instrukcjami obsługi w języku polskim, a jeśli są one niedostępne to w języku angielskim (Zamawiający wymaga, aby urządzenia były rozpakowane i uruchomione wyłącznie przez Wykonawcę, przy czym jest on zobowiązany do poinformowania Zamawiającego o zamiarze rozpakowania sprzętu).

30

Documents

€¦ · Web viewOpis przedmiotu zamówienia. Przedmiotem zamówienia jest: Rozbudowa środowiska kopii zapasowych obecnie eksploatowanego przez Sąd Apelacyjny w Krakowie oraz