Мнгоуровневое резервирование
Простая схема резервирования, рассмотренная в предыдущем разделе часто вполне подходит для персонального использования или маленьких сайтов. Для более тяжелого режима работы больше подходят многоуровневые копии.
Простой метод имеет два резервных уровня: полные и инкрементные копии. Это может быть обобщено для любого числа уровней. Полная копия будет уровнем 0, а различные уровни инкрементных копий будут 1, 2, 3, и т.д. В каждом инкрементном резервном уровне Вы резервируете все, что изменилось, начиная с предыдущей копии в том же самом или предыдущем уровне.
Цель выполнения этого состоит в том, чтобы иметь более длинную историю резервирования (backup history). Например, в предыдущем разделе история резервирования возвратилась к предыдущей полной копии. Это могло бы быть расширено при наличии большего количества лент, но неделя потребовала бы новой ленты, которая могла бы быть слишком дорога. Более длинная история полезна, так как удаленные случайно или разрушенные файлы в течение длительного времени могут оставаться незамеченными. Даже старая версия файла лучше, чем никакого файла вообще.
С многоуровневым резервированием история может быть расширена более дешево. Например, если мы покупаем десять лент, мы могли бы использовать ленты, 1 и 2 для ежемесячных копий (первая пятница в каждом месяце), ленты 3-6 для еженедельно резервирования (другие пятницы; обратите внимание, что могут иметься пять пятниц в одном месяце, так что мы нуждаемся в еще четырех лентах), и ленты 7-10 для ежедневных копий (понедельник-четверг). С еще четыремя лентами мы сможем расширить резервную историю с двух недель (после того, как все ежедневные ленты использовались) до двух месяцев. Да, мы не можем восстанавливать каждую версию каждого файла в течение тех двух месяцев, но того, что мы сможем восстанавливать часто достаточно.
Резервные уровни могут также использоваться, чтобы свести время восстановление файловой системы к минимуму. Если Вы имеете много инкрементных копий с монотонно возрастающим номером уровня, Вы должны восстановить все из них, если Вы должны восстановить целую файловую систему. Вместо этого Вы можете использовать номера уровней, которые не монотонные, и перекрывают несколько копий.
Чтобы минимизировать число лент, необходимых для восстановления, Вы могли бы использовать меньший уровень для каждой инкрементной ленты. Однако, затем вырастет время резервирования (каждая резервная копия перекрывает все, начиная с предыдущей полной копии). Лучшая схема предложена в man-руководстве по команде dump и описана в таблице ниже. Используйте следующую последовательность резервных уровней: 3, 2, 5, 4, 7, 6, 9, 8, 9, и т.д. Такой подход обеспечивает оптимальное соотношение между временем резервирования и восстановления. Число лент для восстановления зависит от того, сколько времени проходит между полными копиями, но это меньше чем в простых схемах.
Таблица 10-1. Эффективная резервная схема, использующая много резервных уровней
| 1 | 0 | n/a | 1 |
| 2 | 3 | 1 | 1, 2 |
| 3 | 2 | 2 | 1, 3 |
| 4 | 5 | 1 | 1, 2, 4 |
| 5 | 4 | 2 | 1, 2, 5 |
| 6 | 7 | 1 | 1, 2, 5, 6 |
| 7 | 6 | 2 | 1, 2, 5, 7 |
| 8 | 9 | 1 | 1, 2, 5, 7, 8 |
| 9 | 8 | 2 | 1, 2, 5, 7, 9 |
| 10 | 9 | 1 | 1, 2, 5, 7, 9, 10 |
| 11 | 9 | 1 | 1, 2, 5, 7, 9, 10, 11 |
| ... | 9 | 1 | 1, 2, 5, 7, 9, 10, 11, ... |
Сложная схема может уменьшить количество трудов, но это означает, что следить придется за большим количеством вещей. Вы должны решить, стоит ли такое наблюдение того, что дает сложное многоуровневое резервирование.
Команда dump имеет встроенную поддержку резервных уровней. Для tar и cpio это должно быть выполнено скриптами оболочки.
