Перейти к содержанию
Форум Челябинских Автомобилистов

Резервное копирование


Рекомендуемые сообщения

Закрепленные сообщения

Нужно организовать на небольшом предприятии резервное копирование,не знаю правда чего лучше (файлов, или же системы в целом(вроде бы как снимок диска)).

Имеется сервер, имеется примерно 10 рабочих машин. Необходимо делать резервное копирование (например раз в неделю), в связи с тем что возможны сбои электричества, уволенный сотрудник специально все стирает ну и всякие прочие обстоятельства...

 

Кто что может посоветовать???

Ссылка на комментарий
Поделиться на другие сайты

Незакрепленные сообщения
Я тут посмотрел, стандартные средства ХР позволяют создать архивирование, но не знаю как оно будет работать... там есть как раз ежедневное архивирование.
Ссылка на комментарий
Поделиться на другие сайты

Т.е. сделать единый обменник на одной рабочей станции (сервере) более "заморочисто" чем делать тоже самое на КАЖДОЙ машине ?))

 

Полностью на данный момент с этим согласен))) как то не аодумал для начала и не оценил.

 

Я тут посмотрел, стандартные средства ХР позволяют создать архивирование, но не знаю как оно будет работать... там есть как раз ежедневное архивирование.

 

Читал я про него, как то не впечатлило.

 

Вы еще не спросили у топикстартера какая сеть ?

есть ли домен (наверно нет раз 10 машин)

 

Верно, домена нет.

 

хотя если сервачек на лине

 

Windows Server 2003

 

Спасибо всем за ответы, советы будем работать дальше)))

У кого какие еще мысли возникнут пишите))буду рад

Ссылка на комментарий
Поделиться на другие сайты

  • 9 месяцев спустя...

подниму тему.

все что тут написано, понятно, небольшое дополнение.

у клиента (я дорос или клиент дорос) очень большая база данных для сохранения около 500г.

пока бекапится раз в неделю, на выходные.

при этом доступность данные должна быть с 7:00 до 24:00, т.е. время на копирование не так и много.

как я делал обычно.

по выходным - полный бекап системы и данных, на неделе - разностный данных, при базе до 50г это занимало около 150-200г места для бекапов.

полный бекап занимал (смотрел по логам, вместе с проверкой) около 2-3х часов.

а вот при больших объемах как правильно делать?

т.е. даже копироваться такой объем данных в отведенное время не успеет.

да и места для полный+(3-4)разностных бекапов надо немерено.

опять же, если выполниться бекап не успеет, значит операция попадает на рабочее время, т.е. сам сервер будет немерено тормозить.

и при этом должен быть не только бекап на другой диск, но на внешний носитель, если это usb или lan1000 то все равно (при 500г) это займет около 5-8 часов с учетом консолидации данных.

плиз подскажите в каком направлении курить.

Ссылка на комментарий
Поделиться на другие сайты

копироваться такой объем данных в отведенное время не успеет.

да и места для полный+(3-4)разностных бекапов надо немерено.

 

А тут ты ничего кроме как поставить на сервак правильные железки не придумаешь.

Нужно стоить крутячий рейд массив на хорошем контроллере для создания бекапа на самом сервере. Который потом будет потихоньку сливаться наружу в рабочее время.

Да и сервак желательно приличный, хотя бы интеловская серверная платформа, с корзинами под диски и нормальным рейд контроллером.

На днях конфигурировали такой. 10 винтов по 2 Тб. При правильном подходе получаем 8 гиговый зеркальный диск и 2 диска в дежурном режиме.

А при твоем объеме базы правилнее так сделать: два диска в зеркало - ОС. 2 диска в зекало под базу. 4 диска в зеркало под бекапы и два диска в дежурный режим.

Тогда надежность и быстродействие будут хорошие.

Изменено пользователем HECTOP
Ссылка на комментарий
Поделиться на другие сайты

А тут ты ничего кроме как поставить на сервак правильные железки не придумаешь.

 

 

т.е. по сути верно, но просто надо более производительное и объемное железо?

 

надеюсь будут еще мнения, т.к почему то мне кажется этот путь тупиковым :)

 

PS: когда попадаются сервера с большим количеством винтов, всегда нравится все их ставить в 0-й рейд и тестить скорость :)

Ссылка на комментарий
Поделиться на другие сайты

Опять же смотри такой момент.

Ну допустим ты все выжал из железа и уложил в отведенное время бекап.

Но какой будет в этом смысл, если в случае сбоя на восстановление оного уйдет полсуток. Контора будет стоять?

Считаем стоимость потерь от времени простоя, и показываем боссу, что ему выгоднее потратиться на железяки сейчас, чем потерять из-за неработоспособности сервера потом гораздо больше.

 

почему то мне кажется этот путь тупиковым :)

 

Гы, гы :)

 

- Моему железу не хватает производительности для бекапа базы, как бы это мне ее забекапить все таки?

- Купить более производительное железо.

- Ну нееет. Это не правильно!

 

Сам то понял чего хочешь?

Изменено пользователем HECTOP
Ссылка на комментарий
Поделиться на другие сайты

Покупай стример, даже одной кассеты хватит и на дифференциальный и на полный бэкап. По скорости LTO-4 на практике выдаёт около 4 Гбайт/минуту, LTO-5 в 1.5 раза быстрее.

Для бэкапа дисковых полок, NAS, используются ленточные библиотеки (например, HP MSL4048).

Вопрос скорости бэкапа решается его правильным планированием и количеством параллельно работающих стримеров.

Ссылка на комментарий
Поделиться на другие сайты

Что это за база на 500 гиг и без SQL типа? А раз SQL - значит транзакции можно накапливать и бэкапить не полностью базу а только изменения. А в 24:00 типа и отрубается сервер? Не смешите мои тапочки. У нас в 02:00 делается принудительное отключение всех юзеров, которые не выключили ПО на ночь и после этого делается бэкап на винты. После этого архивируется спокойно бэкап и пересылается в Москву. Хранятся там. Вообще то есть такое понятие, как дисковый массив, который позволяет "заморозить" данные и потом подкачивать просто изменения. При необходимости делается полный бэкап.
Ссылка на комментарий
Поделиться на другие сайты

Покупай стример, даже одной кассеты хватит и на дифференциальный и на полный бэкап. По скорости LTO-4 на практике выдаёт около 4 Гбайт/минуту, LTO-5 в 1.5 раза быстрее.

Для бэкапа дисковых полок, NAS, используются ленточные библиотеки (например, HP MSL4048).

Вопрос скорости бэкапа решается его правильным планированием и количеством параллельно работающих стримеров.

 

Ты цену озвучь и всякое желание у всех пропадет его покупать))))) я цену знаю))))

  • Плюс 1
Ссылка на комментарий
Поделиться на другие сайты

Тыщи 3 будет стоить, но лучшего решения на сегодняшний день не придумали.

 

Угу, и потому это лучшее решение купленное холдингом вместе с сервером так за 5 лет не разу и не использовалось... На 5 серваков два со стримером встроенным было. В новых серверах уже не закупается.

Ссылка на комментарий
Поделиться на другие сайты

Тыщи 3 будет стоить, но лучшего решения на сегодняшний день не придумали.

 

3 килобакса... И это очень дешево. + софт не забываем! Он стоит столько же сколько сам девайс. + расходники!

Проще полку с дисками купить и винтов. Все быстрый бэкап и всегда он-лайн. Супер!

Ссылка на комментарий
Поделиться на другие сайты

Весь вопрос в надежности. Толку от дисковой полки, если она сгорит вместе с серверной или её зальет водой.

 

А софт есть и бесплатный.

Ссылка на комментарий
Поделиться на другие сайты

Весь вопрос в надежности. Толку от дисковой полки, если она сгорит вместе с серверной или её зальет водой.

 

Ну делайте как у нас. сервак в Челябе - бэкап в Москве. Тут даже ядрен-батон один можно выдержать.

Ссылка на комментарий
Поделиться на другие сайты

выгоднее потратиться на железяки сейчас, чем потерять из-за неработоспособности сервера потом гораздо больше.

...

 

про деньги вроде речи не было, был вопрос про решения.

Гы, гы :)

 

- Моему железу не хватает производительности для бекапа базы, как бы это мне ее забекапить все таки?

- Купить более производительное железо.

- Ну нееет. Это не правильно!

 

Сам то понял чего хочешь?

 

вот когда решаются задачи в лоб, такие решения и предлагаются.

чего хочу я знаю, о чем и сформулировал в своем посте.

 

Что это за база на 500 гиг и без SQL типа?

не поверишь, файловая нормативная база с практическими и рабочими материалами.

 

вообще у меня была мысль о неких копиях файлов в момент обращения юзеров к этим файлам, а затем слив этих копий на резервный носитель.

по крайней мере экономится время на консолидацию данных.

второй вариант, это переход на облачные технологии (тут вообще нет опыта) или аренда сервера в каком нить дата центре.

 

по этому и был вопрос, как решают эти задачи старшие-опытные товарищи, а пока только варианты были "больше, сильнее, толще".

то ли и правда вариантов нет, то ли это совсем не старшие товарищи :).

Ссылка на комментарий
Поделиться на другие сайты

вообще у меня была мысль о неких копиях файлов в момент обращения юзеров к этим файлам, а затем слив этих копий на резервный носитель.

по крайней мере экономится время на консолидацию данных.

 

DFS, как самое простое решение. И бэкап на ленточки :)

второй вариант... или аренда сервера в каком нить дата центре.

 

Смысла нет, если для доступа к файлу необходимо его скачивать. Но можно поднять Citrix ферму в датацентре, тогда все упрется в количество пользователей и быстродействие интернет-канала. По облакам пока рано что-то говорить в нашей стране.
Ссылка на комментарий
Поделиться на другие сайты

не поверишь, файловая нормативная база с практическими и рабочими материалами.

 

А, ну бывает и такое - типа Консультант+ - тоже не хило занимает, но никогда такое не бэкапили, зачем? Есть организация обслуживающая - она и восстановит. А основные рабочие материалы у нас - базы на SQL.

Ссылка на комментарий
Поделиться на другие сайты

как решают эти задачи старшие-опытные товарищи, а пока только варианты были "больше, сильнее, толще".

 

ОК вот история.

Работал в X5.

Когда начинали пятерку в 2002 году SQL центральная база крутилась на 2х процессорном сервере.

В 2006 - 4х процессорный.

В 2008 все мигрировало в московский дата центр в центральном офисе.

Все пользователи по всей России сидели в терминале.

А сейчас там сап и есть центр обработки данных, который вроде в Нижнем построили.

Задача решалась именно наращиванием мускулов.

 

А для другого решения, если оно возможно, нужно знать стркуктуру твоих данных и технологию работы с ними.

А так же требования к отказоустойчивости (о чем уже сказали выше)

Тогда могут появиться и другие решения (но не факт).

Остальное досужие разговоры.

Изменено пользователем HECTOP
Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Сейчас на странице   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу

×
×
  • Создать...