Adres strony internetowej, na której Zamawiający udostępnia

Adres strony internetowej, na której Zamawiający udostępnia Specyfikację Istotnych Warunków
Zamówienia:
www.bip.piekary.pl
Piekary Śląskie: Dostawa sprzętu komputerowego
Numer ogłoszenia: 195165 - 2012; data zamieszczenia: 11.09.2012
OGŁOSZENIE O ZAMÓWIENIU - dostawy
Zamieszczanie ogłoszenia: obowiązkowe.
Ogłoszenie dotyczy: zamówienia publicznego.
SEKCJA I: ZAMAWIAJĄCY
I. 1) NAZWA I ADRES: Prezydent Miasta Piekary Śląskie , ul. Bytomska 84, 41-940 Piekary
Śląskie, woj. śląskie, tel. 032 3939337, faks (032) 287 22 69.
• Adres strony internetowej zamawiającego: www.um.piekary.pl
I. 2) RODZAJ ZAMAWIAJĄCEGO: Administracja samorządowa.
SEKCJA II: PRZEDMIOT ZAMÓWIENIA
II.1) OKREŚLENIE PRZEDMIOTU ZAMÓWIENIA
II.1.1) Nazwa nadana zamówieniu przez zamawiającego: Dostawa sprzętu komputerowego.
II.1.2) Rodzaj zamówienia: dostawy.
II.1.3) Określenie przedmiotu oraz wielkości lub zakresu zamówienia: Dostawa sprzętu
komputerowego. Specyfikacja zamawianego sprzętu: Sieciowy System Kopii Zapasowych I.
Założenia ogólne: System: 1. System kopii zapasowych ma opierać się o architekturę klient-serwer,
z centralnym serwerem zarządzającym procesem backupu oraz klientami (agentami) instalowanymi
na maszynach w sieci. 2. System kopii zapasowych musi umożliwiać promocję każdego z klientów
(niezależnie od wykorzystywanego systemu operacyjnego) zarejestrowanych w centralnym
systemie backupu do funkcji serwera mediów, który może posłużyć do składowania backupu z
innych klientów. 3. Powyższa funkcja ma umożliwiać promocję klienta do funkcji serwera mediów
z wykorzystaniem dedykowanej funkcji interfejsu Web, w szczególności niedopuszczalne jest, aby
konieczne było modyfikowanie plików konfiguracyjnych klienta oraz serwera a także konieczność
zmian na samym kliencie. 4. Funkcja serwera mediów ma umożliwiać wykorzystanie zarówno
lokalnych zasobów dyskowych każdego z klientów, jak również napędu taśmowego oraz biblioteki
taśmowej do nich podłączonych celem zapisania na nich backupu z pozostałych klientów. 5. System
kopii zapasowych ma mieć możliwość wykonywania backupu na dysk, na taśmę (z
wykorzystaniem napędu taśmowego oraz biblioteki taśmowej) a także do chmury utworzonej z
serwerów backupu zainstalowanych w zdalnych lokalizacjach. 6. System backupu ma posiadać
możliwość backupu 2TB (z możliwością rozbudowy). 7. System ma być wyposażony w mechanizm
deduplikacji, który pozwoli zaoszczędzić ilość miejsca na dysku poprzez wyszukiwanie bloków
zapisanych na nośniku w poprzednim zadaniu backupu. 8. System musi być wyposażony w
licencję, która gwarantuje współpracę z bibliotekami taśmowymi z wbudowanymi mechanizmami
robotyki, bez względu na liczbę kaset oraz napędów obsługiwanych przez daną bibliotekę. 9.
System ma mieć możliwość obsługi nielimitowanej ilości napędów i bibliotek taśmowych. 10.
System ma mieć możliwość autodetekcji dowolnego napędu taśmowego i biblioteki, która została
do niego podłączona. 11. Administrator ma mieć możliwość ręcznej definicji dowolnego napędu
taśmowego i biblioteki wraz z informacjami dotyczącymi jego budowy. 12. System ma być
wyposażony w moduł zarządzania licencjami, gdzie poprzez interfejs Web, administrator ma
możliwość dodawania dowolnej licencji. 13. Moduł zarządzania licencjami ma mieć możliwość
dodawania (rozbudowy) poszczególnych funkcjonalności oprogramowania bez konieczności
uruchamiania ponownie żadnego z komponentów oprogramowania. Niedopuszczalna jest
konieczność restartu jakichkolwiek usług wchodzących w skład oprogramowania oraz
jakichkolwiek maszyn wchodzących w skład systemu kopii bezpieczeństwa (włączając w to
maszyny z zainstalowaną aplikacją klienta). 14. System backupu musi mieć możliwość obsługi
nielimitowanej ilości klientów backupu, wliczając w to agentów systemu plików, agentów dla
hypervisorów (VMware, Hyper-V) oraz agentów backupu online następujących usług: a) MS SQL
b) MySQL c) Postre SQL d) Oracle e) MS Exchange f) ActiveDirectory g) LDAP Centralny serwer
backupu: 15. Centralny serwer backupu ma zostać dostarczony w formie urządzenia dedykowanego
wyłącznie do wykonywania kopii bezpieczeństwa danych i zarządzania systemem kopii
bezpieczeństwa 16. Oprogramowanie zainstalowane w urządzeniu powinno bazować na systemie
który nie będzie wymagał od zamawiającego zakupu dodatkowych licencji 17. System operacyjny
w urządzeniu powinien być dostosowany przez producenta w taki sposób, aby nie wymagał od
zamawiającego zarządzania, utrzymywania oraz aktualizacji wewnętrznych komponentów systemu
18. Interfejs zarządzania serwerem backupu ma być dostępny poprzez przeglądarkę internetową. 19.
Funkcjonalność zarządzania systemem przez przeglądarkę ma być dostępna jako funkcja
dodatkowa, system powinien oferować możliwość wyłączenia tej funkcji i zarządzanie systemem
backupu w pełni poprzez środowisko tekstowe CLI, dostępne zarówno bezpośrednio po
podłączeniu klawiatury myszy do urządzenia, jak również poprzez interfejs SSH i dedykowany port
IPMI 20. Interfejs systemu ma być dostępny przez przeglądarkę za pomocą protokołu HTTPS, tym
samym cała komunikacja pomiędzy przeglądarką a systemem ma być szyfrowana. 21. W domyślnej
konfiguracji, interfejs dostępny przez przeglądarkę ma wykorzystywać porty TCP 80 oraz 443. 22.
Administrator ma mieć możliwość zdefiniowania dowolnego portu TCP, na którym nasłuchiwać
będzie interfejs dostępny poprzez przeglądarkę. 23. System ma umożliwiać utworzenie dowolnej
ilości kont użytkowników. 24. Użytkownicy w systemie muszą mieć możliwość przypisania roli
odzwierciedlającej poziom uprawnień. 25. W domyślnej konfiguracji, system ma oferować
minimum 3 rodzaje kont użytkowników systemu: a) Administrator - może wykonywać wszystkie
typy operacji w systemie w tym tworzyć, modyfikować oraz usuwać obiekty i konta użytkowników,
b) Operator - może uruchamiać zadania backupu, ma dostęp z uprawnieniami tylko do odczytu do
konfiguracji systemu, c) Użytkownik - nie może tworzyć, usuwać ani modyfikować jakichkolwiek
obiektów w systemie, ma prawo jedynie do odtwarzania kopii zapasowych. 26. Serwer backupu ma
mieć możliwość połączenia z agentem zarówno za pomocą adresu IP jak również z wykorzystaniem
nazwy DNS. 27. Produkt ma posiadać możliwość replikacji danych pomiędzy wieloma serwerami
backupu zlokalizowanymi w różnych, także odległych lokalizacjach za pośrednictwem sieci LAN
oraz łącz WAN. 28. Proces replikacji danych pomiędzy serwerami backupu ma mieć możliwość
definiowania minimum takich właściwości jak: a) dane przeznaczone do replikacji z dokładnością
do pojedynczego zasobu dyskowego, b) częstotliwość z jaką replikacja będzie się odbywać z
dokładnością do minuty, momentu zakończenia replikacji (musi być możliwość zdefiniowania daty
końcowej, wyłączenia daty końcowej - replikacja ciągła oraz zdefiniowania ilości wystąpień
zadania replikacji, po których polityka przestanie być aktywna), c) retencji z dokładnością do
jednego dnia. 29. Produkt ma posiadać możliwość replikacji danych pomiędzy lokalnymi zasobami
dyskowymi, tym samym administrator ma mieć możliwość zwielokrotnienia tych samych danych
na wielu zasobach dyskowych celem zabezpieczenia danych przed awarią pojedynczego zasobu
dyskowego. 30. Proces replikacji danych pomiędzy lokalnymi zasobami dyskowymi ma być
wyzwalany na żądanie administratora. Administrator ma być w stanie określić przed rozpoczęciem
replikacji: a) źródłowy logiczny zbiór danych do replikacji (z dokładnością do pojedynczego pliku),
b) docelowy zasób dyskowy, na który dane mają zostać zreplikowane, c) czas retencji dla danych
replikowanych. d) włączenie wyłączenie raportowania na e-mail o szczegółach wykonania zadania
replikacji, e) wyłączenie aktualizacji indeksu danych o dane zreplikowane f) ustawienie limitu
czasowego po przekroczeniu, którego proces replikacji zostanie zatrzymany. 31. System ma
umożliwiać rozbudowę o funkcjonalność szyfrowania backupu z wykorzystaniem przynajmniej
takich algorytmów jak 3DES (z PCBC), Blowfish oraz AES256. 32. Klucze szyfrujące nie mogą
być zapisywane razem z danymi backupowanymi. 33. Klucze mają być przechowywane na kliencie
(agencie) a nie na centralnym serwerze backupu. 34. Funkcjonalność szyfrowania danych ma
zabezpieczać zarówno dane przesyłane przez sieć jak również dane zapisywane na centralnym
serwerze backupu. 35. Serwer backupu ma mieć możliwość definiowania parelizmu (maksymalnej
wartości jednoczesnych operacji) dla zasobu dyskowego 36. System ma oferować możliwość
odtwarzania backupu z możliwością określenia: a) czy odtworzone mają być oryginalne prawa na
plikach, b) daty modyfikacji, c) ACL w systemie POSIX oraz atrybutów rozszerzonych Linux, d)
czy nadpisywać pliki, jeśli istnieją na docelowej maszynie, e) czy nadpisywać pliki, jeśli są nowsze
niż te, które znajdują się w backupie. 37. Podczas odtwarzania, administrator ma ponadto mieć
możliwość zdefiniowania systemu innego niż centralny system backupu, który będzie źródłem dla
procesu odtwarzania. 38. System ma oferować możliwość kompresji danych backupu przed
przesłaniem ich poprzez sieć na backup serwer, możliwość ta ma istnieć jako opcja dla każdego z
definiowanych zadań backupu. 39. Algorytm kompresji wykorzystywany do kompresji backupu ma
bazować na algorytmie LZ77, w szczególności niedopuszczalne jest stosowanie zamkniętych
algorytmów kompresji danych. 40. Centralny serwer backupu ma być wyposażony w mechanizm
reindeksacji istniejących taśm z backupem. W przypadku uszkodzenia indeksu, funkcja ta musi
mieć możliwość zaindeksowania taśm utworzonych zarówno na danym centralnym serwerze
backupu, jak i na każdym innym centralnym serwerze backupu wchodzącym w skład środowiska
backupu. 41. Mechanizm reindeksacji taśm ma umożliwiać administratorowi określenie
następujących właściwości procesu przed jego rozpoczęciem: a) w przypadku znanych taśm: wybór
źródłowej taśmy, wybór źródłowego napędu, wybór czy rozpocząć indeksację od momentu jej
przerwania czy od początku nośnika, wybór czy wysunąć taśmę z napędu po zakończeniu procesu
indeksacji oraz czy po zakończeniu procesu przesłać powiadomienie do administratora drogą
elektroniczną z podsumowaniem procesu indeksacji, b) W przypadku nieznanych taśm: wybór
źródłowego napędu, wybór puli taśmowej do podłączenia, wybór typu taśmy - produkt ma zawierać
listę predefiniowanych typów taśm (w tym minimum ma oferować taśmę typu NULL oraz FILE
celem testowania poprawności konfiguracji), zdefiniowania czy w zadaniu użyta ma być biblioteka
taśmowa (jeśli tak, administrator ma mieć opcję wskazania której biblioteki należy użyć podczas
procesu reindeksacji oraz którego slotu tej biblioteki), wybór czy rozpocząć indeksację od momentu
jej przerwania czy od początku nośnika, wybór czy wysunąć taśmę z napędu po zakończeniu
procesu indeksacji oraz czy po zakończeniu procesu powiadomić administratora wiadomością email z podsumowaniem procesu indeksacji. 42. Centralny serwer backupu ma być wyposażony w
mechanizm reindeksacji istniejących zasobów dyskowych z backupem w przypadku uszkodzenia
indeksu. Funkcja ta ma mieć możliwość zaindeksowania dysków z danymi zarówno na danym
centralnym serwerze backupu, jak i na każdym innym centralnym serwerze backupu wchodzącym
w skład środowiska backupu. 43. Mechanizm reindeksacji dysków ma umożliwiać
administratorowi określenie takich właściwości procesu przed jego rozpoczęciem jak: a) w
przypadku znanych dysków: wybór źródłowego zasobu dyskowego, wybór czy rozpocząć
indeksację od momentu jej przerwania czy od początku nośnika oraz czy po zakończeniu procesu
przesłać powiadomienie do administratora drogą elektroniczną z podsumowaniem procesu
indeksacji, b) w przypadku nieznanych dysków: wybór hosta należącego do systemu backupu, do
którego podłączony jest zasób dyskowy, definicja nazwy dla nowo utworzonego zasobu dyskowego
po indeksacji, wskazanie pełnej ścieżki do indeksowanych danych, zdefiniowanie wielkości
wolumenu z dokładnością do 1 megabajta, wybór czy rozpocząć indeksację od momentu jej
przerwania czy od początku nośnika oraz czy po zakończeniu procesu przesłać powiadomienie do
administratora drogą elektroniczną z podsumowaniem procesu indeksacji. 44. System ma być
wyposażony w mechanizm weryfikacji taśm, który umożliwia test czy dane zapisane na taśmie
mogą być poprawnie odczytane. 45. Powyższa funkcjonalność ma umożliwiać administratorowi
zdefiniowanie przed rozpoczęciem procesu weryfikacji minimum następujących elementów: a)
wybór taśmy do weryfikacji, b) wybór napędu, który posłuży do weryfikacji, c) wybór czy wznowić
weryfikację od momentu, w którym proces został przerwany, d) wybór czy wysunąć taśmę z napędu
po zakończeniu procesu weryfikacji e) czy po zakończeniu procesu przesłać powiadomienie do
administratora drogą elektroniczną z podsumowaniem procesu weryfikacji. 46. System ma być
wyposażony w mechanizm duplikacji taśm z zapisanymi na nich kopiami bezpieczeństwa, który
umożliwi utworzenie dowolnej ilości kopii danej taśmy celem zabezpieczenia danych przed awarią
lub zniszczeniem nośnika. 47. Powyższa funkcjonalność ma umożliwiać administratorowi
zdefiniowanie przed rozpoczęciem procesu duplikacji minimum następujących elementów: a)
wybór źródłowej taśmy z danymi do duplikacji, b) wybór napędu, w którym umieszczono źródłową
taśmę, c) wybór napędu, w którym umieszczono taśmę docelową, d) możliwość wyboru czy
podczas procesu będzie wykorzystywana biblioteka taśmowa (jeśli tak, to dodatkowo administrator
ma mieć możliwość zdefiniowania, której biblioteki należy użyć podczas procesu oraz slotu w
którym zainstalowano taśmę docelową), e) możliwość wymuszenia nadpisywania danych na taśmie
docelowej, f) czy po zakończeniu procesu przesłać powiadomienie do administratora drogą
elektroniczną z podsumowaniem procesu duplikacji. 48. System ma być wyposażony w mechanizm
nawigacji, który umożliwia przeglądanie przez przeglądarkę Web zawartości dysków twardych
wszystkich klientów zarejestrowanych w centralnym serwerze backupu oraz dodatkowo jego
własne dane. Dane mają być wyświetlane w formie drzewa katalogów z możliwością przeglądania
ich zawartości. 49. Powyższa funkcjonalność ma działać niezależnie od systemu operacyjnego
klienta oraz serwera. W każdym przypadku administrator ma mieć możliwość przeglądania plików i
katalogów oraz weryfikacji poprawności komunikacji pomiędzy klientem a serwerem. 50.
Mechanizm nawigacji ma oferować możliwość weryfikacji, czy na stacji poprawnie zainstalowano
agenta do hot-backupu aplikacji (agent ma wówczas w drzewie przypisanym do danego klienta
wyświetlać listę takich aplikacji). 51. System ma być wyposażony w mechanizm automatycznego
wykrywania urządzeń takich jak napędy i biblioteki taśmowe, które zostały podłączone do
centralnego systemu backupu. II. Mechanizm deduplikacji danych: 1. System ma być wyposażony
w technologię deduplikacji danych. 2. Deduplikacja ma działać w oparciu o technologię stałej
długości bloku, przy czym długość ta zależna jest od wykrytego typu pliku. Niedopuszczalne jest
stosowanie mechanizmów deduplikacji o zmiennej długości bloku lub o zawsze stałej długości,
niezależnie od typu pliku. 3. Deduplikacja ma działać w oparciu o mechanizm identyfikacji typu
pliku i na tej podstawie, dobierać optymalną wielkość bloku. Program ma mieć wbudowaną bazę
różnego typu plików wraz z odpowiadającymi im rozmiarami optymalnych długości bloku. 4.
Administrator ma mieć możliwość określenia jakie typy plików będą deduplikowane jaką długością
bloku. Funkcjonalność ta ma dawać przynajmniej możliwość zdefiniowania następujących długości
bloków w bajtach dla poszczególnych typów plików: 1024, 2048, 4096, 8192, 16384, 32768,
65536. 5. Administrator ma mieć możliwość zdefiniowania (dla każdego z zadań backupu z
osobna), czy deduplikacja będzie włączona czy nie oraz czy funkcja ta ma być realizowana na
poziomie klienta (agenta) czy po stronie centralnego serwera backupu. 6. Mechanizm deduplikacji
ma mieć możliwość operacji na dowolnych danych, w tym minimum pliki, bazy danych, maszyny
wirtualne, poczta MS Exchange, jak i na każdych innych danych. 7. Mechanizm deduplikacji ma
działać na dowolnym systemie operacyjnym klienta (agenta) w tym minimum na Windows, Linux,
MacOS, FreeBSD, NetBSD, OpenBSD, Solaris. III. Mechanizm łańcuchowania D2D2T: 1.
Oprogramowanie ma być wyposażone w funkcję łańcuchowania backupu Disk-To-Disk-To-Tape
(D2D2T). 2. Funkcjonalność ta ma umożliwiać zdefiniowanie zadania backupu na dysk, które po
zakończeniu automatycznie przeniesie dane na taśmę (za pośrednictwem napędu lub biblioteki
taśmowej). 3. Administrator ma mieć możliwość zdefiniowania odstępu czasu wyrażonego w
minutach, które opóźni moment przenoszenia danych na taśmę w stosunku do momentu
zakończenia zadania backupu na dysk. Czas ten ma być definiowany per zadanie backupu. 4.
Funkcjonalność łańcuchowania D2D2T ma być możliwa także dla backupów zaplanowanych z
harmonogramu. 5. Przy definiowaniu zadania backupu z uaktywnionym łańcuchowaniem D2D2T
administrator ma mieć możliwość określenia polityki wykorzystywania taśm (użycie istniejących
taśm do końca lub wykorzystanie nowych taśm), określenia retencji dla backupu na taśmie oraz
możliwość włączenia szczegółowego raportowania na e-mail o statusie zadania. 6. Administrator
ma mieć możliwość zdefiniowania zautomatyzowanego mechanizmu D2D2T dla danych
zapisanych na dysku, przy czym wyzwolenie zdarzenia łańcuchowania będzie związane minimum
z: wielkością wykorzystywanego miejsca na wybranym zasobie dyskowym z dokładnością do
1MB, ilością pozostałego miejsca na zasobie dyskowym z dokładnością do 1MB. 7. Administrator
ma mieć także możliwość zdefiniowania kolejności z jaką dane będą zapisywane na taśmie,
minimum jako: od najstarszych do najnowszych lub od najnowszych do najstarszych. 8.
Administrator ma mieć możliwość zdefiniowania czy po zakończeniu procesu łańcuchowania
D2D2T dane na zasobie dyskowym mają być usunięte czy pozostawione. IV. Agenci do backupu: 1.
Agent do backupu środowiska wirtualnego VMware vSphere: a) Agent backupu musi wspierać: hot-backup (backup w czasie pracy) dla platformy wirtualizacyjnej VMware Infrastructure w
wersjach ESX 3.0, 3.5, ESXi 3.x, Virtual Center 2.0, 2.5. - Agent backupu ma wspierać hot-backup
(backup w czasie pracy) dla platformy wirtualizacyjnej VMware vSphere w wersjach ESXi 4.x, 5.0,
ESX 4.x, vCenter 4.0, 4.1, 5. - Agent backupu ma wspierać obsługę środowiska wirtualizacji
vStorage na platformach CentOS 5, Red Hat Enterprise Linux 5, 6, SUSE Enterprise Server 10, 11,
Windows Server 2003 SP2, Windows Server 2008 SP1 and R2, Windows Desktop: 7, Vista, XP
SP3. b) Funkcjonalność agenta backupu ma umożliwiać backup zarówno zatrzymanych jak również
pracujących maszyn wirtualnych bez konieczności instalacji agenta na każdej z tych maszyn
(backup na poziomie hypervisora). c) Backup ma być możliwy zarówno dla całych obrazów
maszyn wirtualnych, jak i na poziomie poszczególnych wykorzystanych bloków. d) Backup ma być
realizowany jako backup pełny, jako backup przyrostowy i dyferencyjny na poziomie bloków. e)
Agent backupu ma umożliwiać backup danych fizycznie zapisanych na wirtualnym dysku. f) Agent
backupu ma zapewniać możliwość przywracania danych na poziomie poszczególnych plików oraz
folderów w systemach Windows i Linux dla maszyn wirtualnych (możliwość wyodrębnienia
dowolnego pliku plików oraz katalogu katalogów) z backupu obrazu maszyny wirtualnej. g)
Przywracanie plików z maszyny wirtualnej ma być niezależne i możliwe bez konieczności użycia
platformy VMware (ESX lub vCenter). h) Przywracanie maszyn wirtualnych ma być możliwe z
przekierowaniem Hypervisora (zmiana miejsca docelowego dla odtwarzanego backupu) , jak
również ma zapewnić możliwość wyboru data center, klastra lub hosta docelowego. i) Agent
backupu ma pozwalać na wykonanie backupu na poziomie bloków przy wsparciu technologi Raw
Device Mapping (RDM) wraz z mechanizmem Changed Block Tracking (CBT). j) Agent backupu
powinien integrować się z oprogramowaniem vCenter pozwalając na zarządzanie backupem na
kilku hostach fizycznych. k) Agent backupu ma wspierać rozwiązanie vApp, zapewniając backup
grupy wspólnie pracujących maszyn. l) System ma zapewniać zarządzanie zadaniami backupu i
przywracania dla platformy wirtualnej z poziomu przeglądarki internetowej. m) System ma
wspierać wiele mechanizmów transportu, w szczególności system ma wspierać backup maszyn
wirtualnych bez konieczności użycia sieci LAN (z wykorzystaniem sieci SAN), za pośrednictwem
wirtualnej sieci LAN lub bezpośrednio na urządzenie podłączone za pośrednictwem interfejsu
SCSI. n) System ma mieć możliwość uaktywnienia mechanizmu deduplikacji danych dla backupu
maszyn wirtualnych. o) Funkcjonalność deduplikacji ma być możliwa zarówno na poziomie
centralnego serwera backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta ma być
definiowana (także włączana lub wyłączana) na poziomie pojedynczego zadania backupu. p)
System ma mieć możliwość uaktywnienia kompresji danych dla backupu maszyn wirtualnych. q)
Administrator ma mieć możliwość wyboru pomiędzy przynajmniej dwoma algorytmami kompresji,
przy czym produkt ma umożliwiać wybór minimum algorytmów LZRW1 oraz LZRW3-A. 2. Agent
do backupu środowiska wirtualnego Microsoft Hyper-V: a) Agent backupu ma wspierać hot-backup
(backup w czasie pracy) dla platformy wirtualizacyjnej Microsoft Hyper-V w wersjach Windows
Server 2008 oraz Windows Server 2008 R2. b) Backup ma być możliwy zarówno dla całych
obrazów maszyn wirtualnych, jak i na poziomie poszczególnych wykorzystanych bloków. c)
Backup ma być realizowany jako backup pełny oraz backup inkrementacyjny z wykorzystaniem
technologii śledzenia zmienionych bloków. d) Funkcjonalność agenta backupu ma umożliwiać
backup zarówno zatrzymanych jak również pracujących maszyn wirtualnych bez konieczności
instalacji agenta na każdej z tych maszyn (backup na poziomie hypervisora). e) Agent backupu ma
umożliwiać backup tylko danych fizycznie zapisanych na wirtualnym dysku. f) Agent backupu ma
zapewniać możliwość przywracania wszystkich maszyn wirtualnych lub pojedynczych,
zdefiniowanych przed administratora maszyn. g) Przywracanie maszyn wirtualnych ma być
niezależne. Proces przywracania nie ma wymagać od administratora wykorzystywania innych
maszyn niż centralnego serwera backupu oraz docelowego hosta Hyper-V, na którym maszyny
zostaną odtworzone. h) Przywracanie maszyn wirtualnych ma być możliwe z przekierowaniem
hypervisora (zmiana miejsca docelowego dla odtwarzanego backupu) ze wskazaniem hosta
docelowego. i) Agent backupu ma pozwalać na wykonanie backupu na poziomie bloków przy
wsparciu mechanizmu Changed Block Tracking (CBT). j) System ma zapewniać zarządzanie
zadaniami backupu i przywracania dla platformy wirtualnej z poziomu przeglądarki internetowej. k)
System ma wspierać wiele mechanizmów transportu, w szczególności system ma wspierać backup
maszyn wirtualnych bez konieczności użycia sieci LAN (z wykorzystaniem sieci SAN), za
pośrednictwem wirtualnej sieci LAN lub bezpośrednio na urządzenie podłączone za pośrednictwem
interfejsu SCSI. l) System ma mieć możliwość uaktywnienia mechanizmu deduplikacji danych dla
backupu maszyn wirtualnych. m) Funkcjonalność deduplikacji ma być możliwa zarówno na
poziomie centralnego serwera backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta
ma być definiowana (także włączana lub wyłączana) na poziomie pojedynczego zadania backupu.
n) System ma mieć możliwość uaktywnienia kompresji danych dla backupu maszyn wirtualnych. o)
System ma umożliwiać hot-backup aplikacji pracujących na maszynach wirtualnych z
wykorzystaniem technologii VSS po stronie hypervisora bez konieczności instalacji agentów na
każdej z maszyn wirtualnych. p) Powyższa funkcjonalność ma umożliwiać hot-backup
przynajmniej takich aplikacji jak: Mictosoft Exchange, Microsoft SQL Server, Microsoft Sharepoint
oraz bazy danych Oracle. q) System ma umożliwiać eksport pliku VHD z przeprowadzonego
backupu na maszynę z systemem Windows 7 lub Windows 2008 celem zamontowania pliku obrazu
i odzyskania poszczególnych plików z obrazu maszyny wirtualnej. r) Administrator ma mieć
możliwość wyboru pomiędzy przynajmniej dwoma algorytmami kompresji, przy czym produkt ma
umożliwiać wybór minimum algorytmów LZRW1 oraz LZRW3-A. 3. Agent do backupu
środowiska wirtualnego Xen oraz Citrix XenServer: a) Agent backupu ma wspierać hot-backup
(backup w czasie pracy) dla platform wirtualizacyjnych Xen oraz Citrix XenServer w wersjach 5.5 i
wyższych. b) Backup maszyn wirtualnych bez konieczności instalacji agenta na każdej z
pracujących maszyn (backup na poziomie hypervisora). c) Backup ma być realizowany jako backup
pełny z uwzględnieniem wszystkich maszyn wirtualnych, zarówno pracujących jak również
zatrzymanych. d) Agent backupu ma zapewniać możliwość przywracania wszystkich maszyn
wirtualnych lub pojedynczych, zdefiniowanych przed administratora maszyn. e) Przywracanie
maszyn wirtualnych ma być niezależne. Proces przywracania nie ma wymagać od administratora
wykorzystywania innych maszyn niż centralnego serwera backupu oraz docelowego hosta Xen
XenServer na którym maszyny zostaną odtworzone. f) Przywracanie maszyn wirtualnych ma być
możliwe z przekierowaniem Hypervisora (zmiana miejsca docelowego dla odtwarzanego backupu)
ze wskazaniem hosta docelowego. g) System ma zapewniać zarządzanie zadaniami backupu i
przywracania dla platformy wirtualnej z poziomu przeglądarki internetowej. h) System ma wspierać
wiele mechanizmów transportu, w szczególności system ma wspierać backup maszyn wirtualnych
bez konieczności użycia sieci LAN (z wykorzystaniem sieci SAN), za pośrednictwem wirtualnej
sieci LAN lub bezpośrednio na urządzenie podłączone za pośrednictwem interfejsu SCSI. i) System
ma mieć możliwość uaktywnienia mechanizmu deduplikacji danych dla backupu maszyn
wirtualnych. j) Funkcjonalność deduplikacji ma być możliwa zarówno na poziomie centralnego
serwera backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta ma być definiowana
(także włączana lub wyłączana) na poziomie pojedynczego zadania backupu. k) System ma mieć
możliwość uaktywnienia kompresji danych dla backupu maszyn wirtualnych. l) Administrator ma
mieć możliwość wyboru pomiędzy przynajmniej dwoma algorytmami kompresji, przy czym
produkt ma umożliwiać wybór minimum algorytmów LZRW1 oraz LZRW3-A. 4. Agent do
backupu bazy danych PostgreSQL: a) Agent backupu ma wspierać hot-backup (backup w czasie
pracy) dla bazy danych PostgreSQL w wersjach co najmniej 7.2 i nowszych na platformach
FreeBSD, NetBSD, OpenBSD, Linux, Solaris i Windows. b) Backup ma być możliwy zarówno dla
całych instancji, jak również dla poszczególnych baz danych. c) Backup ma być realizowany jako
backup pełny. d) System ma mieć możliwość uaktywnienia mechanizmu deduplikacji danych dla
backupu bazy danych PostgreSQL. e) Funkcjonalność deduplikacji ma być możliwa zarówno na
poziomie centralnego serwera backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta
ma być definiowana (także włączana lub wyłączana) na poziomie pojedynczego zadania backupu.
f) System ma mieć możliwość uaktywnienia kompresji danych dla backupu bazy danych
PostgreSQL. g) Administrator ma mieć możliwość wyboru pomiędzy przynajmniej dwoma
algorytmami kompresji, przy czym produkt ma umożliwiać wybór minimum algorytmów LZRW1
oraz LZRW3-A. 5. Agent do backupu bazy danych MySQL: a) Agent backupu ma wspierać hotbackup (backup w czasie pracy) dla bazy danych MySQL w wersjach 3.23 i nowszych na
platformach AIX, FreeBSD, NetBSD, HP-UX, Linux, Mac OS, Tru64 i Windows. b) Backup ma
być możliwy zarówno dla całych baz danych, jak również dla poszczególnych tabel. c) System ma
wspierać także backup dziennika binarnego (binary-log), celem późniejszego odtworzenia bazy do
stanu z momentu wykonywania kopii zapasowej. d) Backup ma być realizowany jako backup pełny,
jako backup przyrostowy oraz dyferencyjny. e) System ma mieć możliwość uaktywnienia
mechanizmu deduplikacji danych dla backupu bazy danych MySQL. f) Funkcjonalność
deduplikacji ma być możliwa zarówno na poziomie centralnego serwera backupu jak i po stronie
backupowanej maszyny. Funkcjonalność ta ma być definiowana (także włączana lub wyłączana) na
poziomie pojedynczego zadania backupu. g) System ma mieć możliwość uaktywnienia kompresji
danych dla backupu bazy danych MySQL. h) Administrator ma mieć możliwość wyboru pomiędzy
przynajmniej dwoma algorytmami kompresji, przy czym produkt ma umożliwiać wybór minimum
algorytmów LZRW1 oraz LZRW3-A. 6. Agent do backupu bazy danych MS-SQL: a) Agent
backupu ma wspierać hot-backup (backup w czasie pracy) dla bazy danych MS-SQL w wersjach 7,
2000, 2005, 2008, 2008 R2. b) Backup ma być możliwy zarówno dla całych instancji, jak również
dla poszczególnych baz danych, grup plików oraz indywidualnych plików. c) Backup ma być
realizowany jako backup pełny, kopia (VSS), backup przyrostowy (VDI) oraz dyferencyjny. d)
System ma wspierać relokację baz danych do innych instancji, pracujących nawet na innym hoście.
e) System ma wspierać relokację z jednoczesną zmianą nazwy odtwarzanych obiektów. f) System
ma mieć możliwość uaktywnienia mechanizmu deduplikacji danych dla backupu bazy danych MSSQL. g) Funkcjonalność deduplikacji ma być możliwa zarówno na poziomie centralnego serwera
backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta ma być definiowana (także
włączana lub wyłączana) na poziomie pojedynczego zadania backupu. h) System ma mieć
możliwość uaktywnienia kompresji danych dla backupu bazy danych MS-SQL. i) Administrator ma
mieć możliwość wyboru pomiędzy przynajmniej dwoma algorytmami kompresji, przy czym
produkt ma umożliwiać wybór minimum algorytmów LZRW1 oraz LZRW3-A. 7. Agent do
backupu środowiska Active Directory: a) Agent backupu ma wspierać hot-backup (backup w czasie
pracy) dla środowisk Active Directory w wersjach dla systemów Windows 2003, 2008 oraz 2008
R2. b) Backup ma być możliwy w trybie pełnym, całego katalogu Active Directory c) Backup ma
być realizowany z wykorzystaniem mechanizmu VSS d) System ma wspierać odtwarzanie
środowiska Active Directory w oryginalną lokalizację, na inną maszynę (migracja) oraz w formie
pliku na dowolnej maszynie z zainstalowanym agentem systemu backupu e) System powinien
umożliwiać odtwarzanie autorytatywne z możliwością oznaczania poszczególnych obiektów
drzewa Active Directory f) System ma mieć możliwość uaktywnienia mechanizmu deduplikacji
danych dla backupu Active Directory. g) Funkcjonalność deduplikacji ma być możliwa zarówno na
poziomie centralnego serwera backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta
ma być definiowana (także włączana lub wyłączana) na poziomie pojedynczego zadania backupu.
ciąg dalszy określenia przedmiotu oraz wielkości lub zakresu zamówienia : w sekcji IV.4.16)
Informacje dodatkowe.....
II.1.4) Czy przewiduje się udzielenie zamówień uzupełniających: nie.
II.1.5) Wspólny Słownik Zamówień (CPV): 30.20.00.00-1.
II.1.6) Czy dopuszcza się złożenie oferty częściowej: nie.
II.1.7) Czy dopuszcza się złożenie oferty wariantowej: nie.
II.2) CZAS TRWANIA ZAMÓWIENIA LUB TERMIN WYKONANIA: Okres w dniach: 30.
SEKCJA III: INFORMACJE O CHARAKTERZE PRAWNYM, EKONOMICZNYM,
FINANSOWYM I TECHNICZNYM
III.2) ZALICZKI
• Czy przewiduje się udzielenie zaliczek na poczet wykonania zamówienia: nie
III.4) INFORMACJA O OŚWIADCZENIACH LUB DOKUMENTACH, JAKIE MAJĄ
DOSTARCZYĆ WYKONAWCY W CELU POTWIERDZENIA SPEŁNIANIA
WARUNKÓW UDZIAŁU W POSTĘPOWANIU ORAZ NIEPODLEGANIA
WYKLUCZENIU NA PODSTAWIE ART. 24 UST. 1 USTAWY
• III.4.1) W zakresie wykazania spełniania przez wykonawcę warunków, o których
mowa w art. 22 ust. 1 ustawy, oprócz oświadczenia o spełnieniu warunków udziału w
postępowaniu, należy przedłożyć:
• III.4.2) W zakresie potwierdzenia niepodlegania wykluczeniu na podstawie art. 24 ust.
1 ustawy, należy przedłożyć:
• oświadczenie o braku podstaw do wykluczenia
• aktualny odpis z właściwego rejestru, jeżeli odrębne przepisy wymagają wpisu do
rejestru, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust.
1 pkt 2 ustawy, wystawiony nie wcześniej niż 6 miesięcy przed upływem terminu
składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie
zamówienia albo składania ofert, a w stosunku do osób fizycznych oświadczenie
w zakresie art. 24 ust. 1 pkt 2 ustawy
• III.4.3) Dokumenty podmiotów zagranicznych
Jeżeli wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej
Polskiej, przedkłada:
III.4.3.1) dokument wystawiony w kraju, w którym ma siedzibę lub miejsce zamieszkania
potwierdzający, że:
• nie otwarto jego likwidacji ani nie ogłoszono upadłości - wystawiony nie
wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o
dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania
ofert
• nie orzeczono wobec niego zakazu ubiegania się o zamówienie - wystawiony nie
wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o
dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania
ofert
III.6) INNE DOKUMENTY
Inne dokumenty niewymienione w pkt III.4) albo w pkt III.5)
wypełniony formularz oferty wraz ze specyfikacją oferowanego sprzętu
III.7) Czy ogranicza się możliwość ubiegania się o zamówienie publiczne tylko dla
wykonawców, u których ponad 50 % pracowników stanowią osoby niepełnosprawne: nie
SEKCJA IV: PROCEDURA
IV.1) TRYB UDZIELENIA ZAMÓWIENIA
IV.1.1) Tryb udzielenia zamówienia: przetarg nieograniczony.
IV.2) KRYTERIA OCENY OFERT
IV.2.1) Kryteria oceny ofert: najniższa cena.
IV.2.2) Czy przeprowadzona będzie aukcja elektroniczna: nie.
IV.3) ZMIANA UMOWY
Czy przewiduje się istotne zmiany postanowień zawartej umowy w stosunku do treści oferty,
na podstawie której dokonano wyboru wykonawcy: nie
IV.4) INFORMACJE ADMINISTRACYJNE
IV.4.1) Adres strony internetowej, na której jest dostępna specyfikacja istotnych warunków
zamówienia: www.bip.piekary.pl
Specyfikację istotnych warunków zamówienia można uzyskać pod adresem: Urząd Miasta
Piekary Śląskie ul. Bytomska 84 41-940 Piekary Śląskie Biuro Zamówień Publicznych , pok.218.
IV.4.4) Termin składania wniosków o dopuszczenie do udziału w postępowaniu lub ofert:
19.09.2012 godzina 09:00, miejsce: Urząd Miasta Piekary Śląskie ul. Bytomska 84 41-940 Piekary
Śląskie Biuro Zamówień Publicznych , pok.218.
IV.4.5) Termin związania ofertą: okres w dniach: 30 (od ostatecznego terminu składania ofert).
IV.4.16) Informacje dodatkowe, w tym dotyczące finansowania projektu/programu ze
środków Unii Europejskiej: ciąg dalszy z sekcji II.1.3) Określenie przedmiotu oraz wielkości lub
zakresu zamówienia. h) System ma mieć możliwość uaktywnienia kompresji danych dla backupu
usługi Active Directory i) Administrator ma mieć możliwość wyboru pomiędzy przynajmniej
dwoma algorytmami kompresji, przy czym produkt ma umożliwiać wybór minimum algorytmów
LZRW1 oraz LZRW3-A. 8. Agent do backupu serwera pocztowego MS Exchange: a) Agent
backupu ma wspierać hot-backup (backup w czasie pracy) dla serwera MS Exchange w wersjach
2000, 2003, 2007 i 2010. b) Backup ma być realizowany jako backup pełny, przyrostowy oraz
dyferencyjny zarówno dla magazynów informacji (Information Stores), grup przechowywania
(Storage Groups) jak i baz danych. c) Agent backupu ma wykorzystywać technologie Extensible
Storage Engine (ESE) i Volume Shadow-Copy Service (VSS), wykonując zadania backupu w
trakcie pracy serwera Exchange i nie zakłócając działania usługi. d) Agent backupu ma używać
wbudowanego w Extensible Storage Engine (ESE) interfejsu programowania aplikacji (API),
zachowując przestrzeganie ścisłych formatów backupu Microsoft zapewniając pełną integrację
danych. e) System ma pozwalać na przywracanie danych do Recovery Storage Groups (Exchange
2007) i Recovery Databases (Exchange 2010) na poziomie całych skrzynek jak i poszczególnych
wiadomości. f) Agent backupu ma wspierać usługę replikacji (Site Replication Service),
zapewniając kompatybilność pomiędzy serwerami MS Exchange 5.5 i 2000. g) Agent musi
obsługiwać backup serwerów zarządzających kluczami (Key Management Server), pozwalając na
odzyskanie danych zaszyfrowanych. h) Agent backupu musi umożliwiać pełne przywrócenie bazy
serwera Exchange do stanu z określonego momentu (point-in-time). i) System musi umożliwiać
backup klastrów CCR LCR SCR (Exchange 2007) i DAG (Exchange 2010). j) System ma mieć
możliwość uaktywnienia mechanizmu deduplikacji danych dla backupu środowiska MS Exchange.
k) Funkcjonalność deduplikacji ma być możliwa zarówno na poziomie centralnego serwera
backupu jak i po stronie backupowanej maszyny. Funkcjonalność ta ma być definiowana (także
włączana lub wyłączana) na poziomie pojedynczego zadania backupu. l) System ma mieć
możliwość uaktywnienia kompresji danych dla backupu środowiska MS Exchange. m)
Administrator ma mieć możliwość wyboru pomiędzy przynajmniej dwoma algorytmami kompresji,
przy czym produkt ma umożliwiać wybór minimum algorytmów LZRW1 oraz LZRW3-A. 9. Agent
do backupu serwera LDAP: a) Agent backupu ma wspierać hot-backup (backup w czasie pracy) dla
serwera OpenLDAP oraz innych serwerów LDAP zgodnych z wersją 3 tego protokołu (np. Novell
OES eDirectory) b) Backup ma być możliwy dla całego katalogu struktury LDAP jak również dla
poszczególnych jego elementów z możliwością wyboru CN lub OU do backupu. c) Backup ma być
realizowany jako backup pełny oraz backup przyrostowy dla każdego z elementów struktury LDAP.
d) Proces odtwarzania wybranych elementów, jak również całego katalogu LDAP nie powinien
wymagać zatrzymywania ani restartu usługi katalogowej. e) Konfiguracja danych autoryzacji do
usługi katalogowej LDAP powinna być możliwa zarówno z poziomu pliku konfiguracyjnego
agenta, jak również z poziomu interfejsu Web. f) Agent backupu musi umożliwiać pełne
odtworzenie struktury katalogu LDAP do momentu w którym wykonano backup (odrzucenie
wpisów dodanych w późniejszym okresie) jak również odtwarzanie z zachowaniem tychże wpisów
(z nadpisaniem wpisów uszkodzonych). g) Administrator ma mieć możliwość wyboru pomiędzy
przynajmniej dwoma algorytmami kompresji, przy czym produkt ma umożliwiać wybór minimum
algorytmów LZRW1 oraz LZRW3-A. 10. Agent do backupu bazy danych Oracle: a) Agent backupu
ma wspierać hot-backup (backup w czasie pracy) dla baz danych Oracle w wersjach 8.1.6 i
nowszych na platformach Windows, Linux, HP-UX, AIX, Solaris. b) Backup ma być możliwy za
pośrednictwem narzędzia Oracle RMAN. Niedopuszczalne jest wykorzystanie innych sposobów na
backup bazy danych niż poprzez narzędzie RMAN. c) System ma mieć możliwość uaktywnienia
mechanizmu deduplikacji danych dla backupu bazy danych Oracle. d) Funkcjonalność deduplikacji
ma być możliwa zarówno na poziomie centralnego serwera backupu jak i po stronie backupowanej
maszyny. Funkcjonalność ta ma być definiowana (także włączana lub wyłączana) na poziomie
pojedynczego zadania backupu. e) System ma mieć możliwość uaktywnienia kompresji danych dla
backupu bazy danych Oracle. f) Administrator ma mieć możliwość wyboru pomiędzy przynajmniej
dwoma algorytmami kompresji, przy czym produkt ma umożliwiać wybór minimum algorytmów
LZRW1 oraz LZRW3-A. V. Dedykowane urządzenie komputerowe (serwer sieciowego systemu
kopii zapasowej) do wykonywania kopii bezpieczeństwa danych: 1. Urządzenie powinno być
wyposażone w minimum 2 dyski 3,5 o łącznej pojemności 4TB 2. Urządzenie powinno korzystać z
macierzy RAID poziomu 1, co umożliwi administratorowi za zapisanie 2TB danych 3. Dyski w
urządzeniu powinny być montowane w postaci zatok na froncie urządzenia 4. Zatoki powinny
oferować funkcjonalność hot-swap czyli wymianę dowolnego dysku w czasie pracy urządzenia 5.
Frontowy panel urządzenia powinien mieć możliwość zamknięcia celem ograniczenia dostępu do
zatok dyskowych dla osób postronnych 6. Urządzenie powinno być dostarczone wraz z interfejsem
SCSI, który umożliwi zamawiającemu podłączenie dedykowanego napędu taśmowego lub
biblioteki taśmowej, celem zapisu danych na taśmę 7. Urządzenie powinno mieć możliwość
rozszerzenia o kartę z interfejsem SAS, celem podłączenia dedykowanego napędu taśmowego lub
biblioteki taśmowej, celem zapisu danych na taśmę 8. Urządzenie powinno być wyposażone w
minimum dwa interfejsy GigabitEthernet o prędkości 1Gb s 9. Urządzenie powinno być
wyposażone w dedykowany port IPMI Ethernet celem zarządzania zdalnego urządzeniem (wraz z
dostępem KVM-over-IP), port ten nie powinien być portem wykorzystywanym do zadań backupu
10. Dostarczone urządzenie powinno być w formie sprzętu instalowanego w standardowej szafie 19
o wielkości nie większej niż 2U VI. Informacje dodatkowe dot. specyfikacji systemu: 1.
Dostarczony system musi posiadać dokumentację w języku polskim, co najmniej dwuletnią
gwarancję. Gwarancja na sprzęt obejmuje odbiór i dostawę serwisowanego sprzętu w siedzibie
zamawiającego. 2. Dla wyspecyfikowanego systemu podane parametry są wartościami progowymi
(tzn. minimalnymi), każdy system o parametrach lepszych od wyspecyfikowanych spełnia tą
specyfikację. 3. Wszystkie parametry dotyczą danych producenta systemu z wykorzystaniem jego
firmowych materiałów eksploatacyjnych, w razie jakichkolwiek wątpliwości muszą być
potwierdzone dokumentacją producenta przedstawioną przez oferenta. 4. System powinien spełniać
wszelkie przepisy dot. prawa dopuszczenia do użytkowania w Polsce oraz posiadać stosowne
dokumenty świadczące o spełnianiu wszystkich niezbędnych norm i wytycznych, które powinien
spełniać ww system przed dopuszczeniem go do użytkowania. Kopie tych dokumentów oferent
powinien dostarczyć razem ze systemem, wraz z oświadczeniem o ich zgodności z oryginałem. 5.
W zamówieniu oferowany może być jedynie system fabrycznie nowy, nigdzie nieużywany poza
oczywistą sytuacją związaną z jego testowaniem. 6. Dostawca zobowiązany jest wymienić system
na nowy o takich samych lub lepszych parametrach po 3 kolejnych naprawach serwisowych nie
usuwających objawów awarii. 7. Zgodnie z art. 29 ust. 3 ustawy Prawo Zamówień Publicznych
przedmiotu zamówienia nie można opisywać przez wskazanie znaków towarowych, patentów lub
pochodzenia, chyba że jest to uzasadnione specyfiką przedmiotu zamówienia. W każdym
przypadku w którym użyto znaków towarowych w tej specyfikacji jest to podyktowane specyfiką
zamawianego systemu oraz środowiska i zaplecza systemowo-sieciowego w którym takie
urządzenie musi pracować. Za użyciem ww zapisów przemawia także wymóg 100%
kompatybilności z obecnie posiadaną infrastrukturą sieciowo-systemowo-sprzętową. Przykładowy
system spełniający specyfikację: Arkeia Network Backup System.
IV.4.17) Czy przewiduje się unieważnienie postępowania o udzielenie zamówienia, w
przypadku nieprzyznania środków pochodzących z budżetu Unii Europejskiej oraz
niepodlegających zwrotowi środków z pomocy udzielonej przez państwa członkowskie
Europejskiego Porozumienia o Wolnym Handlu (EFTA), które miały być przeznaczone na
sfinansowanie całości lub części zamówienia: nie