iltmpz
24-07-2009, 16:35
Есть локальная сеть - 100 рабочих станций, 15 серверов, SAN, надо ежедневно бекапить все это.
ОС - windows, linux,
Нужны бекапы разных типов:
- инкрементные, полные (как за последний день, так и за период времени),
- бизнес-данные (БД, файлопомойка, почта), копии системных дисков (как windows, так и linux, freebsd),
- просто периодически выкладывать файлы большого размера.
Также необходима поддержка надежного шифрования файловой системы.
Желательна возможность свободного произвольного доступа к файловому хранилищу бекапов.
Как это работало до недавнего времени:
обычная рабочая станция, 8-портовый SATA-контроллер, 8 дисков 750Гб в RAID-5, OS linux.
При этом бекапы win-серверов делались с помощью acronis через SAMBA, linux-серверов - с помощью rsync через ssh, сопровождение файловой сисетмы/извлечение бекапов - через ssh на сервер.
Однако, в таком решении есть серьезная проблема: периодически (раз в 2-3 месяца) выпадают диски из RAID, ребилд не срабатывает, приходится переразбивать массив, теряя данные.
Интересует оптимальное решение по соотношению емкость/стоимость:
- производительность вторична - RAID-5 из обычных 750Гб SATA устраивает (сейчас за 1 ночь копируется 500 Гб данных),
- непрерывность работы, горячая замена не требуется - если система остановится в любой момент - меня это устраивает. Просто перезагружу и продолжу делать бекапы. Главное, чтобы не повреждались данные.
Какие я вижу варианты:
1. стример для бекапирования SAN.
2. аппаратное сетевое хранилище (типа ISCSI).
Недостатки: непонятна возможность произвольного доступа (просто по ssh не зайдешь), непонятна возможность шифрования (если и есть аппаратное решение, то по-видимому 1 вариант шифрования невысокой стойкости),
в случае SAN - непонятна возможность копировать что-либо еще, кроме SAN и отсутствие произвольного доступа.
3. отдельный сервер с дисковым хранилищем (возможно из тех же дисков 750Гб).
Недостатки: слишком низкая надежность - если RAID будет так же разваливаться - такое решение не подойдет.
4. Возможно, отдельный сервер с каким-то другим типом хранилища или независимое аппаратное решение - не знаю, что это может быть.
Посоветуйте, как лучше всего выбрать решение для подобной задачи?
ОС - windows, linux,
Нужны бекапы разных типов:
- инкрементные, полные (как за последний день, так и за период времени),
- бизнес-данные (БД, файлопомойка, почта), копии системных дисков (как windows, так и linux, freebsd),
- просто периодически выкладывать файлы большого размера.
Также необходима поддержка надежного шифрования файловой системы.
Желательна возможность свободного произвольного доступа к файловому хранилищу бекапов.
Как это работало до недавнего времени:
обычная рабочая станция, 8-портовый SATA-контроллер, 8 дисков 750Гб в RAID-5, OS linux.
При этом бекапы win-серверов делались с помощью acronis через SAMBA, linux-серверов - с помощью rsync через ssh, сопровождение файловой сисетмы/извлечение бекапов - через ssh на сервер.
Однако, в таком решении есть серьезная проблема: периодически (раз в 2-3 месяца) выпадают диски из RAID, ребилд не срабатывает, приходится переразбивать массив, теряя данные.
Интересует оптимальное решение по соотношению емкость/стоимость:
- производительность вторична - RAID-5 из обычных 750Гб SATA устраивает (сейчас за 1 ночь копируется 500 Гб данных),
- непрерывность работы, горячая замена не требуется - если система остановится в любой момент - меня это устраивает. Просто перезагружу и продолжу делать бекапы. Главное, чтобы не повреждались данные.
Какие я вижу варианты:
1. стример для бекапирования SAN.
2. аппаратное сетевое хранилище (типа ISCSI).
Недостатки: непонятна возможность произвольного доступа (просто по ssh не зайдешь), непонятна возможность шифрования (если и есть аппаратное решение, то по-видимому 1 вариант шифрования невысокой стойкости),
в случае SAN - непонятна возможность копировать что-либо еще, кроме SAN и отсутствие произвольного доступа.
3. отдельный сервер с дисковым хранилищем (возможно из тех же дисков 750Гб).
Недостатки: слишком низкая надежность - если RAID будет так же разваливаться - такое решение не подойдет.
4. Возможно, отдельный сервер с каким-то другим типом хранилища или независимое аппаратное решение - не знаю, что это может быть.
Посоветуйте, как лучше всего выбрать решение для подобной задачи?