Что является причиной этой ошибки: Ошибка: EACCES, разрешение отклонено

После долгих экспериментов я нашел решение, хотя и с довольно большим компромиссом.

Сначала пришлось исключить следующие параметры:

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

• Наличие второго зеркального пула ZFS на месте, из которого можно удалить диски для возврата домой. Это более осуществимо, чем первый вариант, но второй пул должен всегда иметь два диска на месте (или использовать две копии данных на одном диске на месте). В настоящее время у меня четыре диска, и больше нет места для пятой в сервере. Это был бы справедливый подход, но все же не идеальный.

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

Мое решение аналогично использованию attach и disach , однако оно использует online и offline . Это имеет то преимущество, что делать дельта-перенос по сравнению с полным переносом, но недостаток заключается в том, что пул всегда сообщает о состоянии DEGRADED (пул всегда имеет два диска; вращающиеся диски вне узла помечаются как автономные , когда они находятся в удаленном месте хранения, а затем переходят в оперативный режим, когда они находятся на узле).

Итак, краткий обзор и обзор моей установки:

у меня есть один сервер ZFS и четыре идентичных диска. ZFS настроен на использование зеркального пула. Два из четырех дисков являются постоянными членами этого пула. Два других диска вращаются; один всегда находится в месте хранения, другой является частью пула и выполняет функцию готового резервного копирования.

Когда придет время повернуть резервные копии:

• Я жду завершения очистки zfs , чтобы убедиться, что диск резервного копирования свободен от ошибок

• I zfs в автономном режиме диск, который будет удален. После отключения I hdparm -Y/dev/id для его вращения. Через минуту я частично извлекаю диск сани (просто достаточно, чтобы обеспечить его потерянную мощность), а затем дать ему еще минуту, прежде чем полностью тянуть диск, чтобы гарантировать, что он перестал вращаться. Диск идет в статическом мешке, а затем защитном корпусе и выходит за пределы площадки.

• Я привожу другой диск вне узла. Он устанавливается в лоток горячей замены и вращается вверх. Я использую zfs online , чтобы восстановить диск в пуле и запустить частичное восстановление, чтобы сделать его параллельным.

Эта система гарантирует, что в любое время у меня будет два зеркальных диска ONLINE и один удаленный диск OFFLINE (который был очищен). Четвертый диск находится либо в режиме переноса данных, либо в оперативном режиме, что дает преимущество, заключающееся в том, что в случае сбоя работающего диска пул будет по-прежнему согласован с двумя подключенными дисками.

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

Обновление: После работы с этим в течение нескольких месяцев я обнаружил, что в моем реальном мире использование Residvering занимает одно и то же время для отсоединения/присоединения и оффлайн/онлайн. В моем тестировании я не думаю, что я запускал очистку - мое предчувствие, что если диск находится в автономном режиме для очистки, то он требует полный Resulver.

В ksh или zsh :

cd dev staging

Этот файл принадлежит пользователю db и группе db :

Access: (0444/-r--r--r--)  Uid: ( 1001/db)   Gid: ( 1001/db)

, но является всемирно читаемым (444). Иерархия каталогов, в которой она находится, отсутствует, но она должна быть доступна для чтения по группе dbp , , если у /home/db нет разрешений по умолчанию. Это может быть так, поскольку ваша маска (027) строже, чем обычно (002).

В противном случае, вероятно, произошла ошибка EACCES, поскольку процесс попытался открыть файл для записи.