При восстановлении данных из испорченных файлов обычно решающее значение имеет доскональное знание внутренней структуры хранения данных, алгоритмы обхода и исправления ошибок в структуре данных. Но иногда возникают дополнительные факторы, которые следует учитывать при обработке битых данных и их восстановлении. Один из таких факторов, о котором хотелось бы рассказать в данной статье – размер файла.
Большинство испорченных файлов, встречающихся нам в работе, относятся к офисным (документы, таблицы, презентации) либо графическим форматам. Также их отличительной чертой является относительно небольшой размер (существенно меньше 10Мб). Связано это с двумя причинами. Во-первых, с огромным количеством пользователей, которые создают и используют файлы этих форматов. Во-вторых, обычно такие мелкие и, как часто считается, не особо важные файлы не попадают в сферу покрытия корпоративного обеспечения сохранности данных. Подобные файлы часто хранятся на переносных хранилищах данных (USB Flash, а иногда и дискеты), что тоже весьма плачевно отражается на их сохранности. При обработке данного класса файлов обычно не возникает проблем связанных с размером входных данных – входной файл при желании можно целиком спроецировать в оперативную память и работать прямо в ней.
Также существенный процент попадающих к нам на восстановление файлов составляют различные базы данных. Размер их обычно колеблется от сотен мегабайт до десятков гигабайт. Обычно такие файлы попадают под действие корпоративных мероприятий по обеспечению сохранности данных, но и это не дает абсолютной гарантии, что данные будут сохранны при тотальном сбое. Большинство этих файлов нецелесообразно или невозможно хранить в памяти. Поэтому при их обработке в оперативной памяти сначала формируется некоторая разметка расположения данных в файле, по которой на следующем шаге восстановления читаются данные, пригодные к восстановлению и формируются выходные данные. В случае потенциально большого объема, занимаемого разметкой файла, а также, если в процессе восстановления надо будет связывать разрозненные куски данных, формирующих один объект (пример – письма в БД хранилища Exchange Server) – используется временная база данных, хранящая разметку.
Но встречаются исключительные случаи – битые базы данных размерами от сотен гигабайт до нескольких терабайт. Разумеется, данные такого объема не могут быть неважными и зачастую именно вокруг такой БД строится работа всей компании. К таким данным очевидно должны применяться все схемы бэкапов, обеспечения надежности хранилищ, но и при всем этом бывают случаи падения баз данных. Про один из таких случаев пойдет речь далее.
ПОСТАНОВКА ЗАДАЧИ
В нашу компанию за поддержкой обратился пользователь, которому было необходимо восстановить базу данных MS SQL Server объемом 1,8 терабайта. Самый большой файл, который нам попадал на обработку до этого случая – 200-гигабайтная БД Exchange Server, так что опыта работы с файлами такого размера не было. Пользователь купил наш продукт для восстановления этого формата баз данных – Recovery for SQL Server (www.officerecovery.com/mssql/), но при попытке восстановить базу программа записывала первые 99999 файлов sql скриптов одной из таблиц и дальше визуально ничего не делала. Решением данной проблемы стало увеличение разрядности счетчика sql-скрипта в имени выходного файла и увеличение количества данных, записываемых в каждый из файлов. После того, как была отослана обновленная сборка программы, пользователь запустил ее опять на восстановление БД, но через несколько дней работы программа упала. Также пользователь пожаловался на не сильно быструю работу программы. Дальнейшая наша работа шла именно на основе этих двух жалоб.
Для ускорения процесса решения указанных проблем мы попросили пользователя переслать нам копию проблемной базы, подписав с нашей стороны соглашение о неразглашении (NDA). База данных пришла на жестком диске, который мы подключили к одному из наших серверов в Калифорнии. Дальнейшие прогоны на реальных данных происходили там.
ИЗМЕНЕНИЯ В ПРОГРАММЕ
При работе над данным запросом улучшение программы преследовало две главные цели:
- принципиальная возможность восстанавливать файлы сверхбольшого объема – если станет возможным восстанавливать базы в 3 терабайта, то можно будет говорить о возможности восстановления баз фактически любого встречающегося размера.
- ускорение работы программы – разница между 4 и 6 часами на восстановление по большей части несущественна, разница между 20 и 30 днями – критична.
В первую очередь было проведено исследование программы по вопросу ее падения на данном файле. Был вариант, что падение связано с недостаточной защитой алгоритма от некорректных данных – в этом случае надо было локализовать, где находятся эти некорректные данные, разобраться с ними и ввести защиту от такой битости. Искать пришлось бы среди примерно 500 отдельных файлов, составляющих эту базу данных. Но подтвердилась другая версия падения – из-за неоптимального алгоритма чтения разметки из временной базы данных на сверхбольших объемах данных не хватало оперативной памяти. Алгоритм был переработан, падение было устранено. Других падений в процессе дальнейшей работы не возникало.
Скорость работы программы улучшалась по двум аспектам:
- Скорость начального разбора базы. Изначально она составляла около двух суток. После переработки чтения файла с отказом от системной буферизации на собственную реализацию буфера чтения время на разбор уменьшилось до 6-7 часов. Также решилась проблема забивания оперативной памяти системным буфером чтения файлов.
- Скорость генерации выходных данных. Так как выходные данные – sql-скрипты, то большую часть процессорного времени тратится на формирование строк из бинарных данных. Была проведена масштабная оптимизация генератора sql-скриптов. Результат – полный прогон восстановления базы без записи на жесткий диск (но с формированием всех выходных данных) – 6 дней 8 часов. Изначально (по расчётам, основанным на частичном восстановлении файла до оптимизации) восстановление заняло бы 25-27 дней.
После полного прогона «виртуального» восстановления базы данных без записи выходных файлов на жесткий диск стала очевидна еще одна проблема – выходные скрипты для воссоздания БД должны были занять 12 730 132 244 866 байт (11,6 терабайт), и их просто негде было хранить.
Для решения проблемы хранения выходных файлов было сделано сжатие sql-скриптов на лету в zip-архивы. Упаковка запускалась в отдельных потоках пачками скриптов примерно по 20 гигабайт, после упаковки соответствующие скрипты удалялись. Но так как генерировались скрипты быстрее, чем запаковывались предыдущие, а при росте количества потоков резко возрастала нагрузка на жесткий диск, то было ограничено количество одновременно работающих на упаковку потоков до четырех. При достижении этого лимита основной поток восстановления приостанавливался и ждал завершения упаковки.
В итоге восстановление базы данных прошло успешно. Время на восстановление – 17 дней, архивирование данных очень замедлило процесс, но пришлось пойти на этот компромисс. Размер упакованных скриптов – 1,1 терабайт. Скрипты были записаны на отдельный жесткий диск и отосланы пользователю. После некоторого времени, нужного на исполнение всех скриптов и возвращения базы в строй, был получен положительный отклик от пользователя.
ВЫВОДЫ
Восстановление даже таких огромных объемов данных возможно, хотя и скорее всего, потребует индивидуального подхода со стороны сервиса восстановления и доработки или настройки программы на конкретный случай.
При возникновении проблем базах данных подобного класса не надо забрасывать программу, которая не смогла сразу восстановить поврежденных файл. Прямое общение с нами в таких случаях поможет доработать программу до уровня, позволяющего осилить даже такие файлы. У OfficeRecovery подобный случай не единственный – нам известно еще о нескольких случаях восстановления баз данных объемом 200-500 гигабайт, и есть уверенность, что мы не обо всех подобных случаях знаем.
Все показатели работы были сняты с работы программы на следующей конфигурации – Intel Core i7 920, 8Gb RAM, 1Tb (system) + 2Tb (input) + 2Tb (output) SATA-2 HDD. Для ускорения восстановления очень поможет отдельный SSD для временного хранения скриптов предназначенных для упаковки.
Не забывайте делать бэкапы и используйте надежные способы хранения. Но помните, что от потери данных не застрахован никто. И если потеря данных все же произошла – OfficeRecovery ждет вас.
Автор: mbozhenko
