В старые добрые времена резервные копии отправлялись на ленты, некоторые из которых часто находились в автономном режиме, если не на удалении. Это затрудняло уничтожение всех резервных копий (случайно или злонамеренно), особенно если сеть / серверы были скомпрометированы.
В наши дни резервное копирование с диска на диск стало модным явлением, поэтому возникают два вопроса:
резервное копирование диск-2-диск, пока диски отключены в удаленном месте: ОК
резервное копирование только в режиме онлайн: не работает
резервные копии, хранящиеся физически рядом с вашим сервером: не в порядке
если ваш сайт будет скомпрометирован и злоумышленник захочет вас остановить - [s] он уничтожит не только ваши данные, но и резервные копии.
взглянуть Вот как люди обрабатывают такие резервные копии.
Очевидно, вы можете поэкспериментировать с методом извлечения резервных копий - так что именно ваш сервер резервного копирования подключается к машинам и копирует файлы. Убедитесь, что машина для резервного копирования недоступна в Интернете, расположена в удаленном офисе / центре обработки данных - это действительно может сработать.
Диск на диск по WAN-ссылке на другой сайт в порядке. Я не сторонник того, чтобы все мои резервные копии были в сети, или чтобы все мои резервные копии были на ленте. Я уже довольно давно участвую в резервной игре, и люди все время говорят: «Лента мертва». Я не думаю, что лента мертва. Диск Disk 2 еще не идеальная замена. Скорость записи на ленту в некоторой степени является ограничивающим фактором, но если вы говорите о резервном копировании с помощью чего-то вроде LTO4, вы достигнете пределов сетевой передачи задолго до того, как достигнете пределов записи на ленту. Если у вас нет 10 ГБ Ethernet. Так что, если вы выполняете резервное копирование на диск по сети, вы, вероятно, не увидите большого скачка скорости на ленте корпоративного класса.
В большинстве случаев резервные копии охватывают несколько непредвиденных обстоятельств: случайное удаление файлов, преднамеренное удаление / уничтожение данных и аварийное восстановление, а иногда и архивирование данных. В зависимости от того, что вам нужно, вам, вероятно, понадобятся ваши данные подальше, чем следующая стойка.
Резервное копирование с диска на диск может иметь разные формы: от копирования файлов по сценарию или вручную до виртуальных ленточных библиотек и дискового хранилища, управляемого вашим программным обеспечением для резервного копирования. VTL и резервное копирование диска, управляемое вашим программным обеспечением, имеют то преимущество, что обеспечивают автономное резервное копирование, которым можно управлять только с помощью программного обеспечения для резервного копирования, и поэтому они не подвержены вмешательству пользователя и менее уязвимы для вирусов или злонамеренных пользовательских атак. Сейчас я использую дедуплицирующую VTL. Раньше у меня был большой кусок пространства SAN, управляемый настройкой NetBackup как дисковое хранилище. Поскольку мой общий объем хранилища на этой арене был ограничен, я использовал его для резервных копий с коротким сроком хранения и незначительного увеличения.
Я не знаю решения d2d, которое предназначено для извлечения и вращения дисков. Поскольку большинство из них используют RAID на всех дисках. Это означает, что ваше хранение ограничено размером вашего диска.
Я решительно выступаю против резервного копирования на диск в Интернете. На самом деле они не защищены от взлома и могут привести к несогласованности данных. Я знаю, что многие люди, особенно здесь, на serverfault, используют их, но я не думаю, что это способ сделать резервное копирование диска наиболее эффективным.
То же самое я испытываю к разбиванию зеркал и движению дисков. Большинство RAID-контроллеров с этим справятся, но восстановление этого RAID-набора требует больших накладных расходов, и в то же время ваша производительность пострадает.
При резервном копировании на жесткие диски приятно то, что они быстрые. При использовании ленточной системы скорость записи на ленту является самым медленным звеном в цепочке. Я думаю, что если бы мы начали использовать жесткие диски для резервного копирования, пропускная способность нашей сети стала бы ограничивающим фактором.
Вероятно, более важным является то, что восстановление может происходить быстрее. Не только из-за скорости накопителей, но и из-за того, что они имеют произвольный доступ, вам не нужно ждать, пока накопитель на магнитной ленте выполнит медленный последовательный поиск, чтобы найти, где начать чтение, прежде чем вы сможете выполнить восстановление. А в случае аварийного восстановления время может иметь решающее значение.
Это зависит.
Резервное копирование с диска на диск идеальный для сценария восстановления службы. Допустим, вам нужно восстановить отключенный сервер в течение 90 минут, 24/7. Вам нужен диск на диск, особенно если вы поддерживаете сервер удаленно.
С диска на диск реплицированное резервное копирование на удаленный сайт аварийного восстановления также прекрасно, так как обеспечивает защиту от сбоев, затрагивающих ваш основной центр обработки данных.
Резервное копирование с диска на диск без репликации не является хорошим выбором, если резервное копирование входит в план обеспечения непрерывности бизнеса в случае сбоя в основном центре обработки данных.
Диск на диск также не является хорошей идеей, если вам нужно сохранить большие объемы данных в течение очень длительного времени. Люди десятилетиями хранят кассеты в старых соляных шахтах ...
ИМО, вы создаете резервную копию, чтобы удовлетворить свою потребность в восстановление службы. Долгосрочное хранение данных (не систем) осуществляется архивом.
Серверы с диски с возможностью горячей замены здесь очень полезны. Вы обращаетесь с дисками как с лентой - вытаскиваете ее после завершения резервного копирования и забираете на хранение.