Назад | Перейти на главную страницу

Резервные копии, снимки JFS2 и потеря питания

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

Таким образом, мы можем потерять значительный объем работы, если сервер каким-либо образом выйдет из строя в конце рабочего дня, но до того, как резервное копирование будет выполнено ранним утром.

Поскольку на сервере работает AIX 5.x, я решил реализовать моментальные снимки JFS2 в файловых системах, требующих резервного копирования, что означает, что я могу сократить время отключения системы при резервном копировании ранним утром до того, что требуется для фактического создания резервной копии. . Это будет наша «гарантированная резервная копия».

Тем не менее, я также хочу попытаться снизить риск потери данных за полные дни за счет создания двух «негарантированных резервных копий» в течение дня без удаления пользователей из системы.

Обоснованием здесь является то, что, если бы мы столкнулись с ситуацией полного отключения питания на сервере, значительная часть файлов данных была бы повреждена - это произошло месяц назад (ИБП взорвал защищенную цепь, отключив сервер - один из таких случаев. вещи, которых никогда не должно было случиться). Однако создание моментального снимка не приведет к повреждению файлов данных в моментальном снимке, а только к возможному повреждению записей, над которыми в настоящее время работают. Или, другими словами, контролируемые, управляемые уровни коррупции, которые можно проверить, если все понимают, что она существует изначально.

Итак, мне нужно задать вопрос:

Насколько хорошо снимки состояния JFS2 справляются с ситуациями полного отключения питания? Во время инцидента, произошедшего в прошлом месяце, мы потеряли около 60% наших данных из-за повреждения, но как бы выглядел снимок этого раздела? Стал бы он тоже пострадать от коррупции или все было бы нормально?

Например, у меня есть / mydata /, и я снимаю его в / mysnapshot в 18:00. В 19:00 мы сталкиваемся с «наихудшим сценарием», и / mydata остается значительно поврежденной. Снимок также будет поврежден? Как AIX и JFS2 справляются с этим в фоновом режиме? Можно ли будет использовать снимок?

Я спешу добавить, что есть также резервные копии на магнитной ленте и удаленные копии файлов, которые создаются в течение 2 часов ночи, поэтому мы не полагаемся на моментальные снимки как на фактическую резервную копию, а просто на средство для улучшения резервного копирования. Дополнительные снимки в течение дня - это определенная изюминка, а не то, на что мы могли бы рассчитывать.

Теоретически пока моментальный снимок зафиксирован на диске (также предполагается, что часть FS или LVM, которая управляет моментальными снимками, обычно не записывается), все будет в порядке.

Но похоже, что ваше приложение плохо использует fsync и может быть улучшено (хотя это будет немного медленнее) с разумным использованием правильной симантики файла posix.

См. Доклад Стюарта Смита «Eat My Data» на linux.conf.au 2007: http://www.linux.org.au/conf/2007/talk/278.html