Вопрос по ошибке при Unattended full repair в DSREPAIR

[Пилютик Михаил]

Процесс Unattended full repair завершается аварийно:

/****************************************************************************/
NetWare 1602.00 Directory Services Repair 20215.03, DS 20217.06
Log file for server ".SNWAPPN.Transistor" in tree "TREE_TR"

** Automated Repair Mode **
Repairing Local Database
Start: Monday, 7 February 2022 16:53:22 Local Time

** All disk amounts are approximations **
Disk space currently available: 3513 MB
->DSRepair may need to use: 258 MB
->Disk space remaining after operation: 3508 MB

Physical Check
Creating Temporary Files
Repair Trees - Scan Values
Repair Trees - Sorting Values
Repair Trees - Scan Entries
Repair Trees - Sorting Entries
Repair Trees - Check Values
Repair Trees - Check Entries
Entry link problem on entry: 0000B3FD - CN=Net192_168_58, problem 4
ERROR: Could not initialize tree check. Error: 1
Total Objects in Database: 8545
Total Objects in Schema : 0
Total External References: 3425
Total Objects in Replicas: 0
WARNING: The current dib set name is set to: NDT
NOTICE: Successfully set current dib set to: nds

Repair process aborted

** Automated Repair Mode **
Finish: Monday, 7 February 2022 16:55:13 Local Time
Total repair time: 0:01:5

Как избавиться от этой проблемы?

В дереве 6-ь серверов. И на одном из них такая проблема.

Сервера все еще:
Novell Open Enterprise Server, NetWare 6.5 Support Pack Revision 08
Server Version 5.70.08 October 3, 2008
Novell eDirectory Version 8.8 SP4 SMP
NDS Version 20217.06 4 November 2008

[Иван Левшин aka Ivan L.]

Михаил, я - удивлен. В документации давным-давно записано: не использовать Unattended Full Repair! Правильная процедура проверки и починки выглядит вообще не так!
По сути проблемы:
1. Роль этого сервера?
2. Есть ли другие реплики раздела с проблемными данными (CN=Net192_168_58, problem 4)?

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

И забудьте, пожалуйста, про Unattended Full Repair!

[Пилютик Михаил]

Михаил, я - удивлен. В документации давным-давно записано: не использовать Unattended Full Repair! Правильная процедура проверки и починки выглядит вообще не так!
По сути проблемы:
1. Роль этого сервера?
2. Есть ли другие реплики раздела с проблемными данными (CN=Net192_168_58, problem 4)?

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

И забудьте, пожалуйста, про Unattended Full Repair!

Добры день, Иван.
Дело в том, что я достаточно давно отошел от собственно eDir, ... (Кстати, Иван, ты обратил внимание на версии того, что стоит у нас?). Видимо поэтому и пропустил многое.

Теперь по существу. Изначально, когда проблема была обнаружена, на этом сервере была реплика R/W, причем в кольце реплик все были синхронизированы. И я пришел к такому же выводу. Удалил с проблемного сервера реплику. Удалял с помощью iManager. При контроле, на серверах с оставленными репликами все Ок - реплика из кольца исчезла, а на проблемном сервере реплику пришлось окончательно удалять с помощью dsrepair -XK2.

[Иван Левшин aka Ivan L.]

Не очень понял вопрос про "обрати внимание": нетварь у вас там стоит, так она у вас давно стоит Не все обновления на нее установлены (по крайней мере едыр успели обновить до 8.8.5, вроде бы... точно не помню), однако вполне себе бодрая 6.5сп8. Очень скучаю по ней...

По лечению: все сделано верно.