Если дошли до этой статьи, то вы наверняка уже ни раз задавались этим вопросом. Возможно вы уже сталкивались с таким и удивлялись что бэкап то я делаю гораздо быстрее чем его восстанавливаю, а может ц вас всё еще впереди. Но в любом случае для некоторых людей это становится реальным сюрпризом, когда они восстанавливают бэкап, особенно первый раз.

Сразу скажу, что решение этой проблемы в данной статье не будет, тут я лишь распишу несколько причин по которым это может происходить. Ну а само решение этих причин возляжет уже на ваши плечи, да и некоторые возможно совсем не получится решить (бюджет всё-таки).

Запись в файловую систему

Потенциальной проблемой может запись в файловую систему, особенно если там уже находятся миллионы файлов или нужно восстановить миллионы файлов. Происходит это потому что для начала перед самим восстановлением этих файлов их нужно создать. А эта операция создания также занимает немало времени и иногда бывает, что создание этих файлов занимает больше времени чем само их восстановление. Т.е. для примера быстрее создать пару файлов чем создавать миллионы.

Скорость записи в RAID

Сейчас многие используют RAID на своих системах, что конечно же хорошо так как терять свои данные никто не хочет. Но у каждого типа RAID есть свои показатели на скорость записи и чтения. Соответственно если вы используете RAID скорость записи которого ниже чем чтение, то проблема медленного восстановление может быть в этом.

Для примера RAID 5, RAID 6 имеют самые маленькие показатели записи на диск по сравнению с другими, при том что RAID 0 самый большой. Да, многие могут возразить что в наше время уже никто не использует RAID 5, так как давно уже есть RAID 50 и т.д. но никто не отменял уже действующие системы хранения с RAID 5 и отсутствием бюджета для изменения этой ситуации.

В интернете много статей на тему сравнения скорости RAID групп можете почитать про это.

Copy-on-write snapshot

Следующей проблемой может служить использование технологии Copy-on-write snapshot. Называется это Copy-on-write потому что перед тем как записать что-то новое на диск все блоки копируются перед тем как пере-записаться. Зачастую такими методами пользуются владельцы NAS систем.

Т.е. если я хочу изменить файл, то система скопирует все блоки, которые занимает данный файл в промежуточный snapshot и только потом произведёт запись в эти блоки. В итоге такая простая манипуляция займёт ажно три операции ввода/вывода: одна операция чтения и две операции записи. Три операции потому что перед изменением блока нужно сперва его прочесть, а затем записать существующий блок в новое место и уже потом записать в этот блок новую информацию.

Если вы изменили файл, который был в snapshot то система сама поймёт в каком именно snapshot его искать. Т.е. система также тратит много времени на то чтобы понять в каком snapshot находится файл к которому вы обращаетесь (их может быть куча). Соответственно, чем больше у вас snapshot-ов тем меньше у вас производительность.

Логи транзакций

Это в основном касается конечно только БД так как реляционные базы данных используют журналы транзакций, в которых записываются все операции с БД. При восстановлении с использованием логов транзакций может быть создано гораздо больше транзакций в секунду чем при обычной записи в обычное рабочее время, что также создаёт нагрузку.

Ленточные накопители

Не знаю насколько это актуально в наше время, но всё же есть еще организации, которые делают бэкап на ленточные библиотеки разных фирм. Можно долго спорить на тему того нужно ли их использовать, но тема нашей статьи другая. И по теме статьи можно сказать что чтение с ленточных библиотек медленное. Такие системы зачатую используют как архивный бэкап, т.е. копия бэкапа.

Да, и ещё один весомый аргумент — это то что приводы такой библиотеки могут выполнять только одно действие чтения или записи. Т.е. если привод сейчас записывает данные, то он не может использоваться для чтения. Но обычно приводов несколько, так что жить можно.