Я ищу простое решение для резервного копирования на месте (т. Е. Не в Интернете) для нашей небольшой компании. Прямо сейчас у нас есть примерно 4 ТБ данных, возможно, добавление ~ 500 ГБ в год. Объем данных, изменяемых в день, намного менее сложен - я думаю, в среднем намного меньше 1 ГБ.
Доступ ко всем данным возможен только из интрасети, и большинство компьютеров работают под управлением Windows, а некоторые работают под MacOS, если это необходимо.
Подробные данные:
(a) Большая часть данных - это изображения / видео / документация (pdf) и тому подобное, я полагаю, 2,5 ТБ.
(б) Часто используются наши файлы данных САПР, но они занимают всего 10-20 ГБ. Они контролируются / доступны централизованной vcs CAD, называемой GAIN (я думаю, что он хранит данные в двоичной базе данных). В настоящее время это сбрасывается вечером, а затем создается резервная копия.
(c) Некоторые данные преимущественно исходного кода уже находятся под контролем версий (SVN, GIT) и занимают менее 2 ГБ.
(d) Некоторые программы имеют только двоичные исходные коды и «заархивированы» в виде zip-файлов. Добавляются новые версии и иногда восстанавливаются некоторые старые версии, но старые версии никогда не меняются. Эти программы занимают около 80 ГБ.
(e) Некоторые личные резервные копии (электронные письма и т. д.) и другие вещи, по-моему, занимают примерно 1 ТБ.
(f) У нас также есть небольшой объем данных на одном сервере Microsoft SQL. Это должно составлять менее 1 ГБ.
Прямо сейчас мы делаем полное резервное копирование с понедельника по пятницу вечером с сетевых дисков на диск локального сервера на ленточный накопитель на сервере. Мы чередуем пятничную ленту, т.е. у нас есть ленты с пометками пн, вт, ср, чт, пт1, пт2. Это означает, что в худшем случае мы не сможем вернуться назад во времени более чем на 2 недели.
Какое хорошее решение для этой неоднородной системы, состоящей из
(а) большие, редко используемые, редко изменяемые, редко добавляемые данные,
(б) частый доступ к довольно небольшим данным, предоставляемым программой внутренне с использованием базы данных,
(c) частый доступ к довольно небольшим данным в рамках «общего» контроля версий,
(d) большие двоичные файлы (~ 100 МБ), которые в основном добавляются, редко читаются, никогда не меняются (необязательно должны быть одноразовыми) и
(e) разные данные, такие как офисные файлы, журналы данных, почтовые папки, которые редко добавляются / изменяются
(f) данные на сервере Microsoft SQL
Я твердо отношусь к программированию, контролю версий и компьютерам в целом, но новичок в стратегиях резервного копирования. Так что было бы хорошо, если бы решение было достаточно простым в обслуживании.
Если возможно, было бы неплохо использовать управление версиями, подобное тому, что предлагается SVN / Git, поэтому последнее успешное резервное копирование позволяет восстановить каждый отдельный файл, когда-либо созданный (а не удаленный вручную).
Проблемы со стратегией на данный момент:
резервное копирование занимает много времени (15 часов)
=> Недостаточно времени, чтобы проверить резервную копию
=> Трудно сказать, действительно ли резервная копия работает
=> Что делать, если время резервного копирования достигает 24 часов?
Решение должно решить все эти проблемы.
Подробнее об использовании времени:
Сбор данных с других серверов по сети на резервный сервер: 02:15
Копирование данных с резервного сервера (который также действует как «обычный» сервер) на другой диск на сервере резервного копирования: 09:00
Скопируйте все данные с внутреннего диска на сервере резервного копирования на ленту, подключенную к серверу резервного копирования: 03:45
Я пытаюсь обобщить, какой был дан совет:
Не существует отдельной обработки репозиториев / баз данных и «простых» данных в отношении резервного копирования (кроме того, что база данных не должна использоваться при резервном копировании).
Пахнет подозрительно, извините.
Сейчас у нас примерно 4 ТБ данных, возможно, добавление ~ 500 ГБ в год.
4000 ГБ - это небольшая резервная копия, которая не займет 17 часов. Как вы это делаете - сеть 1Гбит? Может быть, пора поставить достойную инфраструктуру. Магистраль 10g для сервера резервного копирования, что-то вроде MIcrosoft DPM с локальными агентами изменений и функциональностью, позволяющей пользователям восстанавливать отдельные файлы, 10-12 ТБ дискового пространства на сервере резервного копирования для хранения резервных копий на диске (для быстрого восстановления пользователями) .
Все это хорошо известно и задокументировано - мне кажется, что это в основном ваше определение того, как создавать плохие резервные копии. от недостатка оборудования до недостатка программного обеспечения. Вам следует переоценить свою установку.
backing up takes a long time (17 hours)
- Выполняйте полное резервное копирование по выходным и выполняйте инкрементное резервное копирование в течение недели. Это сократит окно резервного копирования в течение недели, а также сократит объем хранилища, необходимый для ваших наборов резервных копий.
There's not enough time to test the backup
- Что именно вы тестируете? Вам следует выполнять тестовое восстановление небольших наборов данных из наборов резервных копий каждую неделю или каждый месяц. Вам не нужно тестировать восстановление всего набора резервных копий. Восстановите несколько файлов и одну или две базы данных.
Hard to tell if the backup is really working
- См. Номер 2. Вам необходимо протестировать данные восстановления из резервных копий, чтобы узнать, работают ли они. Вы должны делать это достаточно часто, чтобы быть уверенными в надежности резервного копирования и резервного копирования каждую неделю.
What to do if the backup time reaches 24 hours?
- См. Номер 1.
restoring a backup is quite a pain
- Как так? Это процесс? Программное обеспечение для резервного копирования? И т. Д. И т. Д.
restoring something I deleted/modified/overwrote a month ago is not possible
- Получите достаточно носителей для резервного копирования, чтобы удовлетворить ваши потребности в восстановлении. Определите, сколько носителей резервных копий требуется в неделю и сколько недель вам нужно, чтобы иметь возможность вернуться и восстановить. Затем умножьте два. Это даст вам приблизительное представление о том, сколько носителей резервных копий вам нужно, и поможет определить график ротации носителей резервных копий.
РЕДАКТИРОВАТЬ
Чтобы ответить на ваш комментарий:
Что касается восстановления данных, это зависит от программного обеспечения для резервного копирования и от того, какой тип носителя для резервного копирования вы используете. BackupExec использует каталог резервных копий на ленте и на диске. Поиск данных, которые необходимо восстановить, не требует «чтения» лент, пока вы не найдете данные. Требуется только найти данные в окне «Восстановить выбранные элементы» в BackupExec. После того, как вы нашли носитель, на котором хранятся данные, просто предоставить этот носитель для BackupExec. Для дальнейшего развития этого пункта BackupExec рекомендует выполнять резервное копирование на диск, а затем дублировать (копировать) эти резервные копии на ленту. Если вы предоставите достаточно места на диске для выполнения резервного копирования в течение всей недели, тогда все данные, которые вам, возможно, придется восстанавливать в течение всей недели, будут на диске, и вам вообще не потребуется менять ленты местами. Вам просто нужно выбрать данные для восстановления, и BackupExec найдет их на диске.
Что касается типа резервного копирования, то решать вам. Я рекомендую еженедельное полное и ежедневное инкрементное резервное копирование, потому что ежедневное инкрементное резервное копирование будет выполняться быстрее и будет меньше, чем ежедневное дифференциальное резервное копирование, что сэкономит ваше время и деньги (с точки зрения окна резервного копирования и резервного носителя). Случаев, когда для восстановления данных потребуется дифференциальное резервное копирование, очень мало, и я никогда не сталкивался с таким сценарием за 13 лет работы в ИТ-профессии.