Рекомендуемый способ объединения меньшего раздела в один большой каталог

У меня есть определенный раздел на моем сервере (/ var), который заполняется через несколько дней. Я запускаю загруженный почтовый сервер, и все сообщения пользователя отправляются сюда.

Однако теперь мне нужно увеличить объем хранилища, чтобы разместить больше писем.

Filesystem Size Used Avail Use% Mounted on udev 3.9G 4.0K 3.9G 1% /dev tmpfs 796M 556K 796M 1% /run /dev/sda6 254G 32G 209G 14% / none 4.0K 0 4.0K 0% /sys/fs/cgroup none 5.0M 4.0K 5.0M 1% /run/lock none 3.9G 80K 3.9G 1% /run/shm none 100M 0 100M 0% /run/user /dev/sda1 188M 66M 114M 37% /boot /dev/sda7 1.6T 1.2T 364G 76% /var 

Так что читайте много информации в Интернете, и есть несколько рекомендаций.

Первый, с которым я столкнулся, – это использование раздела LVM. Поэтому я могу добавить второй жесткий диск на свой сервер, а затем с помощью LVM объединить два жестких диска в один логический раздел. Пока я все еще читаю, как это сделать, я читал, что если один диск выходит из строя, данные теряются без возможности восстановления. Это как-то послало меня искать вторую альтернативу.

Во-вторых, используется файловая система union, которая позволяет мне объединить несколько каталогов в один. Я до сих пор сталкивался с этими реализациями; unionfs, aufs, mhddfs и overlayfs. В этом случае я могу развернуть второй жесткий диск или занять некоторое пространство из менее заполненного раздела, как в моем корневом корне.

Я пробовал overlayfs на моем localhost, потому что он был добавлен в основное ядро ​​Linux.

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

Во-первых, файловая система overlay / union не является правильным ответом здесь. Это касается случаев, когда у вас есть файловая система только для чтения, которая содержит большую часть ваших данных, и для нее требуется ограниченная настройка поверх того, что доступно для записи (например, LiveCD использует оверлейные файловые системы, чтобы обеспечить впечатление от записываемой файловой системы даже хотя носитель доступен только для чтения).

LVM почти наверняка вы хотите, и он не должен быть ненадежным (он может делать настройки RAID с репликацией). В качестве альтернативы вы можете просто добавить новый (больший) жесткий диск и поместить в него /var , хотя я бы предложил просто поставить /var/mail или что-то другое, на котором находится ваш основной почтовый хранилище, и сохранить остальное, где он находится ,

В идеальной ситуации вы должны смотреть на получение нескольких жестких дисков одинакового размера и работать с RAID10 или RAID5 / 6, установленными для тех, у кого есть /var/mail сверху, а затем работать над тем, чтобы ваши пользователи очищали старые e -mail на сервере (эта ситуация является причиной того, что большинство почтовых провайдеров помещают кепку в почтовое хранилище на сервере).

Ваш лучший вариант – добавить как минимум два жестких диска (например, 4 ТБ или более) и использовать некоторую форму RAID-1 или RAID-10 – если у вас нет избыточности в вашем критически важном сервисе, вы «делаю это неправильно.

Если вы добавляете только два диска, используйте RAID-1. для четырех или более использования RAID-10. Я бы посоветовал не использовать RAID-5 или RAID-6 для почты, потому что для хранения почты требуется LOT пропускной способности ввода-вывода, а RAID-5 намного медленнее, чем RAID-1 / RAID-10 (а RAID-6 еще медленнее) ,

Существует несколько способов реализации RAID-1 / RAID-10, включая mdadm и lvm . С помощью любого из них вы можете создать массив RAID, отформатировать его с помощью предпочтительной файловой системы и установить его вместо /var/mail . Вы также можете добавить больше дисков по мере необходимости в будущем, если ваша файловая система поддерживает рост (например, xfs имеет xfs_growfs , ext2 / 3/4 имеет resize2fs ).

Другой вариант – использовать btrfs . Это имеет встроенную поддержку RAID-подобных функций и автоматически расширяет файловую систему при добавлении к ней дополнительных накопителей. Он также поддерживает обнаружение и исправление ошибок, моментальные снимки, подтомы, прозрачное сжатие файлов и т. Д.

ZFS имеет аналогичные функции для btrfs (и это то, что я лично использую), но имеет тот недостаток, что он (и, вероятно, никогда не будет из-за несовместимости лицензии между CDDL и GPL) частью ядра mainline. Он доступен только как патч или DKMS-модуль. В наши дни это неважно, но это больше.

Моя рекомендация заключалась бы в использовании либо btrfs, либо zfs. ИМО, в наши дни нет никакой веской причины использовать простой старый mdadm или lvm, если вы уже не используете его и не имеете значительного опыта и инвестиций в технологию.

На этом сайте есть множество вопросов и ответов, в которых подробно описываются настройки mdadm, lvm, btrfs и / или zfs и других.

В любом случае, независимо от того, как вы реализуете свою файловую систему RAID или RAID, вам придется перенести свое старое письмо в новую файловую систему с минимальным временем простоя. Во всех случаях процедура будет такой:

  1. установите новые диски. Если у вас нет отсеков с горячей заменой, для этого потребуется некоторое время простоя.

  2. настроить новую рейд и / или файловую систему

  3. установите его как /var/mail.new
  4. rsync /var/mail/ to /var/mail.new/

  5. Вы можете повторять шаг 4 так часто, как хотите, до тех пор, пока у вас не будет времени для завершения этой процедуры (возможно, лучше всего сделать из рабочего времени). Помимо некоторого возможного простоя на шаге 1, до этого момента не должно быть видимого пользователем времени простоя. В лучшем случае они могли заметить, что система работает медленнее, чем обычно, в то время как выполняются задания rsync .

  6. остановите свой MTA (sendmail, exim, postfix и т. д.) и ваши демоны pop / imap и все остальное, что пишет в /var/mail/ . Если у вас есть пользователи, которые заходят в оболочку для чтения почты (например, с помощью mutt), попросите их выйти из системы и не позволить им войти в систему до тех пор, пока вы не закончите.

    Короче говоря, вам нужно остановить все и все, что записывается в любой файл в /var/mail . Вы перезапустите их позже на шаге 13.

  7. запустите окончательный rsync из /var/mail/ в /var/mail.new/ чтобы синхронизировать любые изменения с момента последнего запуска.

  8. mv /var/mail /var/mail.old
  9. mkdir /var/mail
  10. unmount /var/mail.new и заново смонтируйте его как /var/mail (возможно, с mount --move /var/mail.new /var/mail как упоминалось Austin Hemmelgarn)
  11. проверьте права собственности и разрешения /var/mail.old и убедитесь, что /var/mail имеет точно такое же значение.

    Это легко сделать с помощью:

    chmod --reference=/var/mail.old /var/mail

    (note --reference требует версию chmod от GNU, которая является стандартной для Linux)

  12. отредактируйте /etc/fstab чтобы новая файловая система всегда монтировалась как /var/mail после перезагрузки

  13. теперь вы можете перезапустить свои службы MTA, pop и imap и разрешить пользователям снова входить в систему. внимательно следите за ним, чтобы убедиться, что он работает правильно.

  14. в свободное время, когда вы уверены, что новая настройка работает нормально, и вам больше не понадобится старый почтовый каталог, вы можете удалить /var/mail.old и все его содержимое.

BTW, вы получите более 1 ТБ бесплатно в /var после этого. Это может быть чрезмерно для ваших нужд.