Поскольку многие предпочитают сохранять резервные копии данных в нескольких хранилищах, это не идеальный выбор.
Допустим, видеофайл хранится на сервере, который подключен к сотням других серверов в кластере. Механизм резервного копирования автоматически создает резервную копию каждый день в хранилище резервных копий.
Но однажды на диске появляются плохие сектора (необратимое повреждение диска), которые влияют на этот видеофайл.
Механизм резервного копирования просто создает резервную копию видео, как обычно. *nix-сервер не знает, поврежден ли этот видеофайл из-за повреждения диска. Через 2 месяца старый резервный снимок автоматически удаляется из хранилища резервных копий. Таким образом, все копии этого видеофайла являются поврежденными файлами.
Когда посетитель пытается воспроизвести видео этого видеофайла, оно застревает на середине. Представьте, что это происходит на YouTube. Это позор.
Я считаю, что такой механизм резервного копирования неэффективен и требует слишком много места.
Так каков наилучший способ резервного копирования данных в случае сбоя диска?
решение1
Может быть, что-то вроде ежемесячного снимка данных, в дополнение к любым другим ежедневным/ежечасным резервным копиям, которые имеют место. Статические данные выигрывают от этого, поскольку они никогда не меняются, поэтому резервная копия с конца прошлого месяца такая же, как и за месяц до этого, и так далее.
Похоже, вы говорите о простом 2-месячном «полном» стиле резервного копирования, который, конечно, всегда будет в стиле «первый пришел — последний вышел». Даже в самом простом резервном копировании, скажем, с 2-недельной лентой, у вас будет 10 лент, делающих резервные копии MF в течение 2 недель, и в конце месяца. Эти еженедельные 10 лент всегда будут в ротации, и самая старая лента всегда будет перезаписываться каждые 2 недели.
решение2
Вот почемудед-отец-сынИспользуются ротации резервных копий. Хотя я обнаруживаю, что возвращаюсь к лентам за месяцы, потому что пользователь перезаписывал или неправильно использовал свой файл чаще, чем из-за каких-либо проблем с оборудованием.
решение3
Чтобы обеспечить сохранность данных, можно внедрить систему контрольных сумм. Еженедельно перепроверяйте MD5, останавливайте удаление резервных копий в случае возникновения ошибки контрольной суммы. Воспроизведите проблемные файлы из корректной резервной копии.
Длительное хранение данных — это действительно проблема.
Снимки тома не помогают, поскольку если файл не записан между снимками, плохой блок не копируется в файл кэша VSS.
решение4
Когда у вас есть постоянная ошибка диска в секторе, вы будете проинформированы об этом, и резервное копирование этого файла не удастся. Однако, если вы не читаете свои файлы журналов, вам не повезло.