Хорошая стратегия резервного копирования для разнородных данных, состоящих из изображений / баз данных / офисных файлов / репозиториев SVN /
Я ищу простое решение для резервного копирования на месте (то есть не онлайн) для нашей маленькой компании. Прямо сейчас у нас есть приблизительно 4 ТБ данных в общей сложности, возможно, добавляя ~500 ГБ в год. Объем данных, изменяющихся за день, гораздо менее сложен - в среднем я думаю, что он составляет менее 1 ГБ.
Все данные доступны только из интрасети, и большинство компьютеров работают под управлением Windows, а некоторые работают под MacOS, если это имеет значение.
Данные подробно:
(а) Большая часть данных - изображения / видео / документация (pdf) и т. д., я думаю, 2,5 ТБ.
(b) Наши файлы CAD-данных часто доступны, но они занимают всего 10-20 ГБ. Они контролируются / доступны централизованным CAD vcs под названием GAIN (я думаю, что он хранит свои данные в двоичной базе данных). В настоящее время это сбрасывается вечером, а затем резервное копирование.
(c) Некоторые данные в основном из исходного кода уже находятся под контролем версий (SVN, GIT) и занимают менее 2 ГБ.
(d) Некоторые программы имеют только двоичные исходные коды и "архивируются" в виде zip-файлов. Добавляются новые версии, а некоторые старые версии иногда восстанавливаются, но старые версии никогда не меняются. Эти программы занимают примерно 80 ГБ.
(e) Некоторые личные резервные копии (электронные письма и т. д.) и другие вещи занимают примерно 1 ТБ, я думаю.
(f) У нас также есть небольшой объем данных на одном сервере Microsoft SQL. Это должно составлять менее 1 ГБ.
Прямо сейчас мы делаем полное резервное копирование каждый вечер с понедельника по пятницу с сетевых дисков на диск локального сервера и на ленточный накопитель на сервере. Мы чередуем ленту по пятницам, т.е. у нас есть ленты, помеченные как mo,tue,wed,thu,fri1,fri2. Это означает, что в худшем случае мы не сможем вернуться назад во времени более чем на 2 недели.
Какое хорошее решение для этой гетерогенной системы, состоящей из
(а) большие редко используемые, редко изменяемые, редко добавляемые данные,
(б) частый доступ к довольно небольшим данным, предоставляемым программой изнутри с использованием базы данных,
(c) частый доступ к довольно небольшим данным под "общим" контролем версий,
(d) большие двоичные файлы (~100 МБ), которые в основном добавляются, редко читаются, никогда не изменяются (по желанию могут быть одноразовыми) и
(д) разные данные, такие как офисные файлы, журналы данных, почтовые папки, которые редко добавляются / изменяются
(f) данные на сервере Microsoft SQL
Я хорошо разбираюсь в программировании, управлении версиями и компьютерах в целом, но плохо знаком со стратегиями резервного копирования. Так что было бы хорошо, если бы решение было достаточно простым в обслуживании.
Если возможно, было бы неплохо создать версию, подобную SVN/Git, поэтому последняя удачная резервная копия позволяет восстановить каждый отдельный файл, который когда-либо создавался (а не удаляется вручную).
Проблемы со стратегией до сих пор:
резервное копирование занимает много времени (15 часов)
=> Недостаточно времени для тестирования резервной копии
=> Трудно сказать, действительно ли работает резервная копия
=> Что делать, если время резервного копирования достигает 24 часов?
- восстановление бэкапа это довольно больно
- восстановить что-то, что я удалил / изменил / переписал месяц назад, невозможно
Решение должно решить все эти проблемы.
Использование времени в деталях:
Сбор данных с других серверов по сети на сервер резервного копирования: 02:15
Скопируйте данные с сервера резервного копирования (который также действует как "обычный" сервер) на другой диск на сервере резервного копирования: 09:00
Скопируйте все данные с внутреннего диска на сервере резервного копирования на ленту, прикрепленную к серверу резервного копирования: 03:45
3 ответа
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 лет в ИТ-профессии.
Я пытаюсь обобщить, какой совет был дан:
- получить выделенный сервер резервного копирования, чтобы производственные серверы не могли свободно меняться, когда все данные находятся на сервере резервного копирования
- если время резервного копирования слишком велико, переключитесь с полного резервного копирования каждый день на полное резервное копирование в пятницу и инкрементное / дифференциальное резервное копирование с понедельника по четверг
- Тестов резервного копирования будет достаточно, когда будет выполнено резервное копирование в пятницу или когда у нас будет выделенный сервер резервного копирования, может быть, каждый день (если он автоматизирован и, следовательно, не занимает моего времени)
- Получите достаточно лент, чтобы мы могли восстановить данные давно
- Чтобы ускорить восстановление, можно даже сделать резервную копию на диске в дополнение к резервным копиям на ленте.
- Инкрементное резервное копирование в течение недели должно быть предпочтительным, так как оно быстрее, а преимущества дифференциального резервного копирования используются редко.
Не существует отдельной обработки хранилищ / баз данных и "простых" данных в отношении резервного копирования (за исключением того, что база данных не должна использоваться при резервном копировании).
Это пахнет подозрительно, извини.
Прямо сейчас у нас есть приблизительно 4 ТБ данных в общей сложности, возможно, добавляя ~500 ГБ в год
4000gb - это не большая резервная копия, и она не должна занимать 17 часов. Как вы это делаете - 1-гигабитная сеть? Может быть, пришло время положить в приличную инфраструктуру. Магистраль 10 г для сервера резервного копирования, что-то вроде MIcrosoft DPM с локальными агентами изменений и функциональностью, позволяющей пользователям восстанавливать отдельные файлы, 10-12 ТБ дискового пространства на сервере резервного копирования для хранения резервных копий некоторое время на диске (для быстрого восстановления пользователями),
Это все хорошо известные и документированные вещи - мне кажется, что это в основном ваше определение того, как делать резервные копии, это плохо. от недостатка оборудования до недостатка программного обеспечения. Вы должны пересмотреть ваши настройки.