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