В данной статье я хочу рассказать о проблеме сохранения данных.
Все мы когда-то сталкиваемся с тем, что нам нужно сохранить важную информацию, будь-то фотографии, текстовые документы, базы данных 1С:Предприятие всех конфигураций или любая другая важная для нас информация. Многие пользователи не хотят тратить свое время или не знают, как написать правильно небольшой «батник» для копирования своих данных. Вот для этого и существуют небольшие программы для бэкапа различных данных. Подробнее о резервном копировании можете прочитать .
С необходимость автоматического бэкапа я столкнулся, когда мне потребовалось каждодневное копирование баз данных с 1С:Предприятия. При поиске, удобной и отвечающей моим требованиям, программы, я нашел то что мне нужно — это программа Cobian Backup 11 . Эта программа оказалась с очень понятным и не сложным интерфейсом, а самое главное она бесплатная, что в наше время очень хорошо.
1. Установка программы
И так перейдем к установке программы. Скачиваем дистрибутив программы с официального сайта и запускаем скаченный файл. На первой странице инсталлятора выбираем тот язык который вам нужен и нажимаем «Далее» .
На следующей страничке нам предложат ознакомиться с лицензионным соглашением и принять условия этого соглашения. Жмем «Далее» .
Перед нами появляется вот такое окно с выбором: куда и что установить.
- «Инициатор теневого копирования» служит для того, чтобы копировать файлы, даже тогда, когда они открыты или используются приложениями. Я рекомендую его установить, но если допустим бэкап вам нужен для одного раза, то в принципе инициатор теневого копирования можно не устанавливать. Для работы инициатора теневого копирования требуется наличие установленного Microsoft .NET Framework 3.5 . Как установить компоненту.NET Framework в , читайте .
- «Сценарий установки» нужен для того, что бы запомнить все параметры текущей установки, и при следующей установке, сделать все то же самое, без вашего участия.
По умолчанию нам предлагают установить эту программу как службу, рекомендую оставить все как есть, если вы будете использовать её на сервере или на том компьютере, где есть несколько пользователей. Во первых в виде службы программа будет работать даже если ни кто не выполнил вход в систему, во вторых программа сможет использовать сетевые ресурсы, для хранение данных на ftp-сервере, на другом локальном компьютере в вашей сети или на сетевом хранилище.
В случае если она вам нужна например для разового использования или вам не слишком часто придется к ней обращаться, то можете выбрать любой из пунктов по вашему выбору.
При установке программы как службы, нужно обязательно указать учетную запись администратора и пароль .
Все, на этом установка закончена.
2.Настройка программы
Приступим к основной задаче настройки задания бэкапа. Запускаем программу, в меню выбираем «Задание» ,
затем «Новое задание» .
Запустится мастер создания нового задания. Здесь задаем «Имя» задания, устанавливаем необходимые галочки и выбираем «Тип копирования » .
Переходим на вкладку «Файлы» , потом нажимаем «Добавить» , что бы указать, что нам копировать и куда.
Указываем файл, каталог или папку на ftp сервере которую вам необходимо скопировать. Так же указываем куда копировать выбирая из списка. Все должны понимать, что делая бэкап и сохраняя его на тот же жесткий диск, при его физическом крахе, сводит на нет все ваши усилия, восстановить информацию будет проблематично, при сохранении на разные разделы диска, спасет вас только в случаях, когда у вас слетит раздел, где находиться основная информация или при удалении. Поэтому старайтесь сохранять ее на независимый носитель, например сетевое хранилище, внешний жесткий диск, флешку или на компьютер находящийся в одной сети, ну и конечно же на ftp сервер.
Переходим в закладку «Расписание» . Как видите, настройки тут на любой случай жизни, настраиваете как вам удобно: хоть раз в год, хоть каждый день в определенное время.
Переходим на вкладку «Цикличность». З десь можно настроить приоритет вашего задания и для экономия места можно настроить число хранения полных копий.
Переходим на вкладку «Сжатие» и указываем какое нам нужно сжатие и деление на части ваших файлов.
3. Заключение
В целом мне очень понравилась эта программа, я думаю многим она придется по душе. Очень понятный и простой интерфейс не вызовет проблем с настройкой, тех заданий, которые вам могут понадобиться в повседневной жизни.
Помогла ли Вам Данная статья?
Недавно моя подруга попросила объяснить ей, как делать резервное копирование данных. Она гуманитарий, поэтому ей нужны были варианты, в которых ничего настраивать не нужно. Так как она - человек не глупый, который любит сам разбираться в проблеме и принимать решение, я решила собрать для нее основные принципы и описать плюсы и минусы тех или иных вариантов (как я их вижу). Опубликовать здесь я решилась на тот случай, что кому-то из вас пригодится – помочь другу или родственнику. Буду очень рада комментариям о том, как можно было бы сделать текст проще и понятнее.
Основные принципы
1. Регулярность и частота
Backup данных должен быть таким же регулярным, как прием таблеток. Именно за эту дисциплинированность себя можно будет благодарить, если вдруг произошел какой-то крах. Порой потерять даже всего несколько рабочих дней из-за того, что backup не сделан, - может быть очень болезненным. Ответить на вопрос - как часто делать бэкап возможно, поняв, данные за какой промежуток времени тебе было бы наименее болезненно терять. Один из оптимальных вариантов - backup данных раз в неделю по выходным.Раздельность
Желательно, чтобы данные сохранялись на отдельный внешний жесткий диск (или другой носитель), хранились в отдельном месте от основных данных. Принцип вполне очевиден - если произошла проблема, она будет локализована в одном месте. Например, если сломался жесткий диск на компьютере, диск с резервной копией будет функционировать отлично. Тем не менее, здесь стоит соблюдать баланс между легкостью доступа и безопасностью. Жесткий диск, стоящий рядом с компьютером, существенно повышает мотивацию использовать его по назначению. И в то же время, это не самый безопасный вариант для очень важных данных, которые терять нельзя ни в каком случае. Именно поэтому различают резервное копирование и архивацию данных.Перепроверка
Как только сделана первая резервная копия данных, необходимо сразу проверить, что из нее эти данные можно восстановить! Это означает не только то, что файлы становятся видны. Нужно открыть несколько файлов на выбор и проверить, что они не испорчены. Желательно такую проверку потом повторять раз в какой-то период (скажем, раз в год).Различение
Лучшая практика - различать данные по категориям. Категорией может быть их важности для тебя, частота обновления, или просто тематика.Зачастую программы резервного копирования делают так называемые «образы» (image). Они выглядят как один единственный файл. Так вот в каждый такой образ лучше сохранять различные данные.
Для чего это нужно. Данные разной важности требуют разного обращения с собой, это очевидно. Свои важные документы, наверняка, захочется хранить более бережно, чем, скажем, коллекцию фильмов. Разделив данные по частоте обновления можно, к примеру, сэкономить время занимаемое резервным копированием. Тематика - какие данные желательно вместе восстанавливать за один шаг? Яркий пример двух типов backup, которые следует делать раздельно:
Резервное копирование данных
Это документы Word, фотографии, фильмы и т.д. Так же к этому относятся, но часто забываются - закладки в браузере, письма в почтовом ящике, адресная книга, календарь со встречами, конфигурационный файл банковского приложения и т.д.Резервное копирование системы
Речь идет об операционной системе со всеми ее настройками. Такой backup избавляет от необходимости устанавливать операционную систему заново, делать все настройки, устанавливать программы. Однако, это не самый из необходимых типов резервного копирование.Куда делать backup
1. Внешний жесткий диск. Часто можно купить прямо в коробке. Бывают ноутбучные - такие диски маленькие по размеру, но более дорогие. Обычные жесткие диски можно сравнительно дешево купить объемом в 2 Тб - тогда за место на диске долго не придётся беспокоиться.Достаточно надежный (если не ронять и не трясти чрезмерно)
+ Относительно недорогой
Необходимо самому не забывать подключать диск для бэкапа
-Не очень удобно переносить (не относится к ноутбучным дискам)
2. USB-stick - подойдет как дополнительное средство, когда данные хотелось бы переносить с одного компьютера на другой и/или иметь под рукой. Так же если сами данные не хочется хранить на компьютере.
Есть одно большое но - у флешки ограничено число записей, так что если на ней хранить данные приложения, которое будет интенсивно записывать, то флешка (usb stick) довольно быстро прикажет долго жить. К тому же, по моему личному впечатлению, они достаточно часто ломаются. Мой знакомый, покупая самые дорогие флешки, которые позиционировались как «не убиваемые», получал сломанную флешку за месяц-другой. Справедливости ради, надо сказать что у меня до сих пор ни одна флешка не сломалась, некоторые работают уже лет 5. Тем не менее, только на одном только usb-stick`e я бы хранить данные не стала.
Мобильное хранение
+Занимает мало места
+Очень дешево
Непредсказуемая надежность
3. Хранение данных на удаленном сервере (или в облаке).
Есть свои плюсы и минусы:
Данные будут доступны не только дома, но и на работе, во время путешествий.
+Локационная раздельность основных данных и резервных копий (например, если случается, не дай бог, пожар данные выживают)
+Нет нужды подключать жесткий диск для бэкапа, как правило, все делается полностью автоматически.
Желательно шифровать данные, так как неизвестно кто к ним может получить доступ
-Тратится большой объем трафика (если он ограничен, то возникают проблемы)
-Зачастую бесплатно можно хранить только данные до 2 Гб. Так что, такой backup - это дополнительная статья расходов
Список с хорошим описанием сервисов можно найти
Чем делать backup
Приведу список приложений, на которые стоит обратить внимание (по моему мнению), при резервном копировании на жесткий диск.
Из бесплатных пользуются популярностью
1. Genie Backup Manager - очень удобная программа, но немного тормозит при работе
2. Handy Backup - простой интерфейс, работает быстро.
Дополнительно
Часто в настройках программ по backup есть опция - сделать инкрементальный или дифференциальный backup. Практическое различие довольно простое. При дифференциальном резервном копировании можно сэкономить на месте которое он занимает. Зато есть только две возможности восстановления: данные в том состоянии, когда был сделан полный backup + данные на тот момент, когда был сделан дифференциальный.Инкрементальный backup же позволяет откатиться на любой из моментов в прошлом, когда делалось резервное копирование. Однако, особенно если изменения в данных происходили часто, место будет съедаться быстро.
Настоящее и будущее журналирования
Существует множество определений журналируемых файловых систем, однако давайте приведем формулировку, понятную каждому: журналируемая файловая система - это систем для тех, кому надоела программа проверки fsck во время загрузки. Также это система для тех, кому близка идея устойчивых к сбоям систем. Если некорректно отключить питание в обычной системе, где отсутствует журналирование, то ОС обнаруживает этот факт и запускает утилиту проверки целостности диска fsck при следующей загрузке. Эта утилита сканирует файловую систему и пытается устранить проблемы, не нанося вреда данным. Процесс проверки может занять довольно много времени. Иногда файловая система повреждается настолько сильно, что ОС загружается только в однопользовательском режиме и предлагает пользователю провести дальнейшее восстановление.
Скажи fsck
Еще хуже то, что процесс fsck может запускаться операционной системой автоматические при монтировании файловой системы, чтобы удостовериться, что метаданные верны (даже если не было повреждений). Таким образом, устранение лишних проверок целостности файловой системы - это заметная область для улучшения.
Итак, теперь вы знаете, кто нуждается в журналируемых файловых системах, однако почему таким системам не нужны проверки fsck ? Вкратце - потому, что в них ведется специальный журнал. Журнал - это файл, представляющий собой кольцевой буфер, в который заносятся все действия, связанные с изменением файловой системы. Периодически эти изменения применяются к файловой системе. В случае сбоя, журнал может быть использован в качестве отправной точки для восстановления несохраненных данных и для предотвращения повреждения метаданных.
Резюмируя, скажем, что журналируемая файловая система - это устойчивая к сбоям файловая система, команды изменения для которой заносятся в журнал, прежде чем быть исполненными, что помогает избежать повреждения метаданных. (См. рисунок 1). Как обычно в Linux, существует множество вариантов таких систем. Давайте сделаем небольшой обзор истории файловых систем, а затем рассмотрим имеющиеся на сегодня файловые системы и их различия.
Что такое метаданные?
Метаданными называются служебные структуры данных, необходимые для хранения основных данных. Такие операции, как создание и удаление файла и каталога, увеличение файла, усечение файла и.т.д., затрагивают метаданные.
Рисунок 1. Типичная журналируемая файловая система.
История журналируемых файловых систем Linux
IBM® первой разработала журналируемую файловую систему, которая называлась JFS (Journaled File System). Первая версия JFS была представлена в 1990 году, а современная версия поддерживается в Linux как JFS2, разработанная позже. В 1994 году компания Silicon Graphics представила высокопроизводительную файловую систему XFS для ОС IRIX. В 2001 году XFS была портирована для Linux. В 1998 году для систем Amiga была разработана файловая система Smart File System (SFS), которая впоследствии выпускалась под лицензией GNU Lesser General Public License (LGPL) и получила поддержку в Linux 2005 году. Наибольшее распространение получила файловая система ext3fs (от англ. third extended file system ), которая является расширением системы ext2 с добавлением журналирования. Поддержка ext3fs появилась в Linux в 2001 году. И наконец, получившая широкое распространение журналируемая файловая система ReiserFS открыла много новых путей и возможностей для развития. Однако развитие этой системы замедлилось в связи с юридическими проблемами ее автора.
Разновидности журналирования
Все журналируемые файловые системы ведут журнал для буферизации изменений файловой системы (который также нужен для аварийного восстановления), однако существуют различные стратегии того, что и когда заносить в журнал. Существует три наиболее распространенные стратегии - режим обратной записи, режим упорядочивания и режим данных.
В режиме обратной записи журналированию подвергаются только метаданные, а блоки с данными записываются непосредственно на диск. Это способствует нерушимости структуры файловой системы и защищает от повреждений, однако повреждение самих данных все же возможно (например, если крах системы наступает после записи метаданных в журнал, но до записи блока с данными). Решить указанную проблему позволяет режим упорядочивания . В этом режиме в журнал заносятся также только метаданные, но сами данные записываются до журналирования метаданных. Этим гарантируется согласованность данных файловой системы после восстановления. И наконец, возможно журналирование в режиме данных , при котором в журнал заносятся как метаданные, так и сами данные. Этот режим обладает наивысшим уровнем устойчивости к повреждению и потере данных, но имеет недостаток в виде низкой производительности, поскольку все данные записываются дважды (сначала в журнал, потом на диск).
Правила применения изменений, зафиксированных в журнале, также могут быть разными в разных подходах. Например, когда следует применять изменения? Когда журнал полон? Или когда истекает некий таймаут?
Журналируемые файловые системы сегодня
На сегодняшний день активно используется несколько журналируемых файловых систем, каждая из которых имеет свои преимущества и недостатки. Ниже представлена четверка самых популярных журналируемых файловых систем.
JFS2
JFS2 (также известная как улучшенная журналируемая файловая система ) является первой журналируемой файловой системой и долгое время применялась в ОС IBM AIX®, прежде чем была перенесена в Linux. JFS2 - это 64-разрядная файловая система, которая, имея корни оригинальной JFS, была заметно усовершенствована в плане масштабируемости и поддержки многопроцессорных архитектур.
JFS2 поддерживает упорядоченное журналирование, обладает высокой производительностью и временем восстановления менее секунды. Для повышения быстродействия в ней применяется метод размещения файлов на основе экстентов. Размещение на основе экстентов означает размещение файла в виде нескольких непрерывных участков, а не множества одинаковых блоков. Благодаря непрерывности, эти участки обеспечивают более быстрое чтение и запись. Дополнительное преимущество экстентов - меньшие расходы на работу с метаданными. При размещении файла блоками записи подлежат метаданные каждого блока. Если используются экстенты, то изменяются метаданные для экстентов, которые обычно состоят из нескольких блоков.
JFS2 также использует B+-деревья как для эффективного поиска по каталогам, так и для управления дескрипторами экстентов. JFS2 не имеет собственной политики переноса изменений на диск, - вместо этого она основывается на таймауте демона kupdate.
XFS
XFS - еще одна из ранних журналируемых файловых систем, первоначально разработанная Silicon Graphics в 1995 году для ОС IRIX. В 2001 году XFS была реализована в Linux, уже будучи на тот момент продуманной и надежной файловой системой.
XFS использует полноценную 64-разрядную адресацию и обеспечивает очень высокую производительность за счет применения B+-деревьев для размещения каталогов и файлов. XFS хранит данные в виде экстентов, поддерживая переменный размер экстентов (от 512 байт до 64 килобайт). Наряду с экстентами в XFS применяется отложенное размещение, при котором размещение блоков задерживается до тех пор, пока не наступит время их записи на диск. Такая особенность повышает вероятность заполнения подряд нескольких дисковых блоков, поскольку на момент записи будет известно их количество.
Другие интересные свойства XFS - это гарантированная скорость ввода/вывода, когда пользователям файловой системы выделяется резерв пропускной способности для операций ввода/вывода, и прямой ввод/вывод, при котором данные копируются напрямую между диском и буфером приложения (вместо того чтобы проходить несколько буферов). Журналирование в XFS ведется методом обратной записи.
Третья расширенная файловая система (ext3fs)
Третья расширенная файловая система (ext3fs) - наиболее популярная журналируемая файловая система, возникшая как эволюция известной файловой системы ext2. На самом деле она совместима с ext2, так как оперирует идентичными структурами, но с добавлением журнала. Более того, возможно смонтировать раздел ext3 как ext2 либо преобразовать ext2 в ext3, используя утилиту tune2fs .
В ext3fs поддерживаются все три стратегии журналирования (обратная запись, упорядочивание и режим данных), однако по умолчанию используется режим упорядочивания. Политику переноса данных журнала на диск можно настраивать, но изначально она такова, что перенос происходит либо по заполнении 1/4 журнала, либо по истечении одного из таймеров переноса.
Один из главных недостатков ext3fs происходит из того, что она изначально не задумывалась как именно журналируемая файловая система. Поскольку она основана на ext2fs, в ней отсутствуют многие прогрессивные нововведения, имеющиеся в других файловых системах (например, экстенты). Также она обычно показывает слабую производительность по сравнению с ReiserFs, JFS и XFS, однако меньше нагружает процессор и потребляет памяти, чем многие другие файловые системы.
ReiserFS
Что такое уплотнение хвостов?
Очень часто бывает, что файл имеет размер, меньший размера логического блока. Вместо того чтобы выделять на каждый такой файл по целому блоку, оставляя часть блока незанятой (эту часть называют хвостом ), в один блок стараются уместить несколько файлов. Такой способ дает выигрыш в 5% свободного места по сравнению с другими файловыми системами, но негативно сказывается на производительности.
Файловая система ReiserFS с самого начала создавалась как журналируемая. В 2001 году она была добавлена в главную ветку ядра 2.4 и стала первой журналируемой файловой системой, появившейся в Linux. Основной метод журналирования - упорядочивание. Поддерживается увеличение размера файловой системы "на лету". ReiserFS также поддерживает уплотнение хвостов для динамического уменьшения фрагментации, что позволяет ей обгонять по скорости ext3fs при работе с маленькими файлами.
В ReiserFS (также ее называют ReiserFS v3) применяется много современных подходов, например B+-деревья. Формат файловой системы базируется на единственном B+-дереве, что делает операции поиска особенно быстрыми и масштабируемыми. Политика переноса данных из журнала на диск зависит от размера журнала и основана на количестве блоков, требующих переноса.
Репутация ReiserFS была несколько раз подпорчена: последний раз - проблемами автора системы с законом (подробную информацию см. в разделе ).
Будущее журналируемых файловых систем
Ознакомившись с журналируемыми файловыми системами настоящего и прошлого, давайте посмотрим, что их ждет в будущем (и что не ждет).
Reiser4
После успешного внедрения ReiserFS в ядро и применения во многих дистрибутивах Linux компания Namesys (которая стоит за ReiserFS) начала работу над новой журналируемой файловой системой, Reiser4, которая была создана полностью с нуля и включает в себя множество передовых возможностей.
Улучшенное журналирование в Reiser4 достигается за счет использования блуждающих записей и отложенного размещения блоков до момента переноса данных журнала (как это было сделано в XFS). В архитектуре Reiser4 предусматривалась гибкая поддержка плагинов (например, чтобы добавить функции сжатия или шифрования), но эта идея была отвергнута Linux-сообществом, которое считало, что место этим расширенным функциям - в подсистеме виртуальной файловой системы (VFS).
После вынесения обвинения владельцу Namesys и одновременно автору ReiserFS вся коммерческая деятельность вокруг Reiser4 была приостановлена.
Четвертая расширенная файловая система
Четвертая расширенная файловая система (ext4fs) - это дальнейшее развитие ext3fs. Ext4fs была задумана как замена ext3fs, имеющая с ней прямую и обратную совместимость, но включающая в себя множество улучшений (некоторые из которых нарушают эту совместимость). На практике можно монтировать раздел ext4 как ext3 и наоборот.
Во-первых, ext4fs - это 64-разрядная файловая система с поддержкой томов огромного размера (до 1 эксабайта). Она также может использовать экстенты, но в этом случае теряется совместимость с ext3fs. Аналогично XFS и Reiser4, в ext4fs размещение блоков на диске задерживается и происходит по необходимости (что уменьшает фрагментацию). Журнал также хранит контрольные суммы содержимого для большей надежности. Вместо B+- или B*-деревьев применяется специальная разновидность B-дерева, т.н. H-дерево , что позволяет поддиректориям иметь намного больший размер (в ext3 он ограничен 32Кб).
Хотя отложенное размещение уменьшает фрагментацию, со временем файловая система большого размера все равно фрагментируется. Для решения этой проблемы была разработана утилита e4defrag, которую можно использовать для дефрагментации отдельных файлов или целой файловой системы.
Еще одно интересное отличие ext4fs от ext3fs заключается в точности временной метки файлов. В ext3 размерность временной метки - одна секунда. Ext4fs смотрит в будущее: при непрекращающемся росте скоростей процессора и интерфейсов требуется более точное измерение. Поэтому в качестве размерности времени была взята одна наносекунда.
Хотя ext4fs включена в ядро Linux в версии 2.6.19, она уже может считаться стабильной. Эта система, разработка которой продолжается, является отправной точкой для создания журналируемой файловой системой будущего в Linux.
Двигаясь дальше
Журналируемые файловые системы обеспечивают надежность и защиту от повреждения данных при крахе системы или потере питания. Помимо этого, время восстановления в таких системах намного меньше, чем в традиционных файловых системах (например таких в которых применяется fsck). Разработка новых методов журналирования основывается как на прошлом опыте, идущем от JFS и XFS, так и на поиске новых алгоритмов и структур. Не совсем ясно, как будут развиваться журналируемые файловые системы в будущем, однако их полезность очевидна, и они уже стали новым стандартом файловых систем.
При обычной работе файловой системы все изменения обычно сразу производятся с диском (вернее с кэшем диска в ОС, но это в данном контексте не важно).
Многие операции требует одновременного изменения сразу нескольких структур файловой системы (метаданных . Простой пример: при создании hardlink"а нужно одновременно увеличить количество ссылок на inode и изменить содержимое каталога, в который делается ссылка. Нельзя сделать лишь одну из этих операций — содержимое файловой системы будет некорректным.
При обычной работе файловой системы подобная комплексная операция всегда выполняется целиком, если код реализации файловой системы не содержит критических ошибок. Однако при нештатной перезагрузке или аппаратном сбое эта ситуация вполне реальна.
Так как после перезагрузки мы не знаем какие операции производились, что было незакончено, а знаем только о том, что диск не был корректно размонтирован (при этом сбрасывается так называемый dirty flag), то нам необходимо проанализировать файловую систему на всём диске, и, таким образом, выявить все ошибки в файловой системе и их исправить. Естественно далеко не всегда это возможно выполнить автоматически (неестественный интеллект, увы, способностям к ясновидению пока обучить никому не удалось), посему та же fsck.ext2 после нештатной перезагрузки может потребовать и ручного вмешательства.
Те, кто запускал fsck на разделе в 100-200 G (что ныне далеко не редкость) прекрасно понимают, что удовольствия в этом мало. Администраторы же многотерабайтовых массивов, за лишнюю минуту простоя коих им могут «случайно» голову оторвать при слове fsck хватаются за валерьянку или просят не ругаться такими словами в их присутствии.
Для решения этой проблемы давным-давно была придумана гениальная идея (если кто знает когда и кем — скажите мне, пожалуйста) — сначала записать некое описание планируемой операции на диск, а уж потом её выполнять. Тогда можно будет не тестировать весь диск на корректность, а всего лишь ограничиться просмотром содержимого журнала, и, если операция не была завершена, то откатить её. Для этого не нужно запускать fsck — это делает сам драйвер файловой системы.
Подводя итог — единственное что может и должна делать журналируемая файловая система, это экономить время на fsck. Соответственно гарантируется непротиворечивость метаданных файловой системы, не больше, не меньше.
Цена этого удовольствия: у нас образуется небольшая (обычно измеряемая десятками мегабайт) область диска, на которую приходится максимальная нагрузка, то есть максимальное производительность, измеряемая в количестве i/o операций в секунду, падает. Ну и, естественн, расходуется немного дискового пространства, что в эпоху цен на диски < 1$/гигабайт никого не волнует.
Журналирование данных
Как вы обратили внимание, в журнал обычно пишутся операции с метаданными. Однако можно то же самое делать и с данными.
Насколько мне известно под Linux журналирование данных умеет выполнять лишь ext3 с параметром data=journal.
Разумеется журналирование данных во многих случаях несколько уменьшает производительность (но далеко не всех, на сайте IBM есть результаты тестов, по которым использование журналирования данных для файловых систем, на которых находятся базы данных, может дать даже прирост производительности).
Это средство тоже не гарантирует сохранность данных, однако из моего личного опыта использование ext3 с data=journal является самой надёжной файловой системой.
Производительность
Внимательный читатель наверняка заметил, что использование журнала это создание неравномерной нагрузки на диск — на одну маленькую (по сравнению с общим размером файловой системы) область приходится несоразмеримой объём операций.
Есть два очень интересных решения:
Во-первых можно вынести журнал на отдельный диск (большинство файловых систем это позволяют), в результате мы фактически удваиваем производительность добавлением всего одного диска. Это особенно красиво смотрится, когда производительность огромного RAID-массива увеличивается таким простым и дешёвым способом.
Во-вторых можно использовать специальные карты энергонезависимой памяти (например UMEM, коих я, увы, на территории России в продаже не видел), которые ещё и заметно быстрее обычных дисков (но имеют небольшой размер памяти).
Есть ещё совсем экстравагантное решение, которое я пока не опробовал — сделать журнал на блочном устройстве расположеном в памяти. Разумеется после перезагрузки такоую файловую систему надо будет пересоздавать заново, но для временных данных это может дать интересное и заметное увеличение производительности. Особенно при журналировании данных, а не только метаданных.
Хитрости
Как вы уже убедились, журнал может давать и прирост скорости. Есть ещё несколько оригинальных трюков, которые может использовать журналирующая файловая система для ещё большего увеличения производительности:
- отложеное создание файла (в момент создания файла не создавать сразу запись в каталоге, а некоторое время держать её только в журнале, возможно файл временный и будет сразу удалён);
- отложеное размещение файла (не выделять физически место даже под первый блок файла до тех пор, пока не понадобится записать хотя бы один блок), вполне возможно, что пользователь сначала изменит размер файла, а уж потом начнёт записывать данные. Как результат уменьшается фрагментация (если программы пользуются этим трюком);
Это самые простые, есть ещё множество маленьких ухищрений, которые позволяют журналируемой файловой системе работать быстрее обычной, оставаясь более надёжной.
Недостатки
Как я уже говорил журнал не панацея, и данные ничуть не спасает. Однако у многих создаётся от использования журналируемых файловых систем ложное чувство безопасности — как же, можно ведь резетом машину перезагружать, и даже не матюгнётся при загрузке!
Да, не матюгнётся. И будет абсолютно корректной с точки зрения какого-нибудь fsck файловой системой. Только вот от данных при этом всё равно могут остаться одни ошмётки.
Скажем reiserfs в подобных ситуациях вполне может оставлять в модифицируемых файлах мусор (произвольные данные которые были в выделеном под файл блоке). Что, по сути, означает вполне вероятную случайную утечку информации.
XFS поступает более корректно — она такие блоки прописывает нулями. Что часто шокирует пользователей. Особенно фанатов reiserfs, которая не станет прописывать нулями.
В результате reiserfs скорее сохранит модификации, а XFS всеми силами избежит мусора в файлах и утечки данных — просто чуть разные стратегии. Результат один — данные могут быть утеряны, и вы даже об этом не узнаете. Пока не столкнётесь с файлом, который уже год никто не трогал (в архиве лежал), и который вдруг оказался забитым мусором или нулями.
ext3 с включеным журналированием данных такими особенностями не страдает. Однако заметно проигрывает в производительности.
По-хорошему всех этих проблем можно (и нужно) избежать просто покупкой UPS, а журналирование использовать лучше как дополнительный уровень надёжности и средство увеличения производительности.
Итог
Журналируемая файловая система всего лишь немного облегчает администрирование, однако не является волшебным средством от потери данных при нештатных перезагрузках. Поэтому если вы не пользуетесь UPS и не делаете Backup, то ваши данные рано или поздно накроются медным тазом, чего я вам искренне НЕ желаю. А если захотеть, то можно использовать журналируемые файловые системы как средство увеличения производительности.
Кто купил UPS И backup делает Того данные всегда целы
(C) Денис Смирнов
Размещение этого документа на других Internet-ресурсах, а также в печатных изданиях не допускается.
Журналируемые файловые системы - это класс файловых систем, характерная черта которых - ведение журнала, хранящего список изменений, в той или иной степени помогающего сохранить целостность файловой системы.
Запуск проверки системы (например, fsck) на больших файловых системах может занять много времени, что очень плохо для сегодняшних высокоскоростных систем. Причиной отсутствия целостности в файловой системе может быть некорректное размонтирование, например, если в момент прекращения работы на диск велась запись. Приложения могли обновлять данные, содержащиеся в файлах, и система могла обновлять метаданные файловой системы, которые являются «данными о данных файловой системы», иными словами, информация о том, какие блоки связаны с какими файлами, какие файлы размещены в каких директориях и тому подобное. Ошибки (отсутствие целостности) в файлах данных - это плохо, но куда хуже ошибки в метаданных файловой системы, что может привести к потерям файлов и другим серьезным проблемам.
Для минимизации проблем, связанных с целостностью, и минимизации времени перезапуска системы, журналируемая файловая система хранит список изменений, которые она будет проводить с файловой системой перед фактической записью изменений. Эти записи хранятся в отдельной части файловой системы, называемой «журналом», или «логом». Как только изменения файловой системы безопасно внесены в журнал, журналируемая файловая система применяет эти изменения к файлам или метаданным, а затем удаляет эти записи из журнала. Записи журнала организованы в наборы связанных изменений файловой системы, что очень похоже на то, как изменения добавляемые в базу данных организованы в транзакции.
Наличие журнала повышает вероятность сохранения целостности файловой системы, потому что записи в лог-файл ведутся до проведения фактических изменений, и эти записи хранятся до тех пор, пока они не будут целиком и безопасно применены. При перезагрузке компьютера программа монтирования может гарантировать целостность журналируемой файловой системы простой проверкой лог-файла на наличие ожидаемых, но не произведенных изменений и последующей записью их в файловую систему. Т.о. при наличии журнала в большинстве случаев системе не нужно проводить проверку целостности файловой системы, а это означает, что компьютер будет доступен для работы практически сразу после перезагрузки. Соответственно, шансы потери данных в связи с проблемами в файловой системе значительно снижаются.
Существует несколько журналируемых файловых систем, доступных в Linux. Наиболее известные из них:
XFS, журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source);
ReiserFS, журналируемая файловая система разработанная специально для Linux;
JFS, журналируемая файловая система первоначально разработанная IBM, но сейчас выпущенная как открытый код;
xt3 - журналируемое расширение файловой системы ext2, используемой на большинстве версий GNU/Linux. Уникальная особенность системы ext3 - возможность перехода на неё с ext2 без переформатирования диска. Разработана доктором Стефаном Твиди (Stephan Tweedie).
В семействе ОС Microsoft Windows к журналируемым относится файловая система NTFS. В Mac OS X - HFS+.
