А это зависит от фич бэкап софта. Просто как пример - я периодически делаю бэкап всяких важных файлов и документов для offsite backup путем просто копирования ряда фолдеров на большой USB drive и потом этот drive хранится в моей банковской ячейке. Копирование делается просто массовым копированием файлов (так сделано сознательно, по ряду причин).
Так вот, в этой схеме проверка бэкапа делается легко и просто - перед копированием я прогоняю утилитку которая читает исходные файлы и генерирует дайджест с их MD5 хэшами, а после копирования (для проверки бэкапа) та же самая утилитка прогоняется по файлам в бэкапе и сравнивает MD5 хэши в тем что в дайджесте. Поначалу я это делал для того чтобы убедится что файлы переписались без каких-либо сбоев, но это же позволяет проверять бэкап очень простыми и надежными средствами.
Если делать бэкап генерируя некий архив/архивы, то часто бэкап софт имеет такую функцию.
Еще один важный фактор - насколько волатильными являются файлы и фолдеры. Для себя я давно придерживаюсь схемы - важные файлы и документы рассматриваются как read-only (исключения есть но их мало). Проверять бэкап таких файлов легко и просто, просто сравнением файлов в бэкапе с исходными файлами.
Но это все относится к традиционным бэкапам. Как часть data protection strategy я использую RAID, и поверх рейда - snapshots которое защищает от случайных удалений и изменений файлов. Проверка интегрити тут встроена в сам механизм - e.g. RAID.
... Side note - вот это предложение ну *очень* проблемное, с секьюрити пойнт оф вью. Это один из классических но тем не менее популярных способов как раз.ебать секьюрити вашего сервиса в ноль, не делайте так для реальных прод сервисов.
>>>Например, на сервер для разработки. >>>Заодно разработчики получат возможность протестировать функциональность на данных, восстановленных из production.
Реальные рабочие данные из прод *никогда* нельзя выносить из прода, тем более на дев машины. Аналогично и с прод сертификатами, кредами и т.п.
no subject
А это зависит от фич бэкап софта. Просто как пример - я периодически делаю бэкап всяких важных файлов и документов для offsite backup путем просто копирования ряда фолдеров на большой USB drive и потом этот drive хранится в моей банковской ячейке. Копирование делается просто массовым копированием файлов (так сделано сознательно, по ряду причин).
Так вот, в этой схеме проверка бэкапа делается легко и просто - перед копированием я прогоняю утилитку которая читает исходные файлы и генерирует дайджест с их MD5 хэшами, а после копирования (для проверки бэкапа) та же самая утилитка прогоняется по файлам в бэкапе и сравнивает MD5 хэши в тем что в дайджесте. Поначалу я это делал для того чтобы убедится что файлы переписались без каких-либо сбоев, но это же позволяет проверять бэкап очень простыми и надежными средствами.
Если делать бэкап генерируя некий архив/архивы, то часто бэкап софт имеет такую функцию.
Еще один важный фактор - насколько волатильными являются файлы и фолдеры. Для себя я давно придерживаюсь схемы - важные файлы и документы рассматриваются как read-only (исключения есть но их мало). Проверять бэкап таких файлов легко и просто, просто сравнением файлов в бэкапе с исходными файлами.
Но это все относится к традиционным бэкапам. Как часть data protection strategy я использую RAID, и поверх рейда - snapshots которое защищает от случайных удалений и изменений файлов. Проверка интегрити тут встроена в сам механизм - e.g. RAID.
...
Side note - вот это предложение ну *очень* проблемное, с секьюрити пойнт оф вью. Это один из классических но тем не менее популярных способов как раз.ебать секьюрити вашего сервиса в ноль, не делайте так для реальных прод сервисов.
>>>Например, на сервер для разработки.
>>>Заодно разработчики получат возможность протестировать функциональность на данных, восстановленных из production.
Реальные рабочие данные из прод *никогда* нельзя выносить из прода, тем более на дев машины. Аналогично и с прод сертификатами, кредами и т.п.