Опишите точно процедуру бэкапа. Действительно, есть вероятность, что повреждены данные в /var/lib/samba/locking.tdb, поскольку Самба очень чувствительна к поведению файловой системы. См. http://ozlabs.org/~rusty/index.cgi/tech/2009-10-20.html

Алгоритм бэкапа

# lvs
File descriptor 7 (pipe:[500644]) leaked on lvs invocation. Parent PID 5038: bash
  LV                VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  ovz               lvm0 -wi-ao   4,97G

1. lvcreate -s -L 1G -n ovz-snapshot /dev/lvm0/ovz
2. mount -o ro /dev/lvm0/ovz-snapshot /mnt/snapshot
3. tar -c /mnt/snapshot -f /mnt/backup/ovz.tar
4. umount /mnt/snapshot
5. lvremove -f /dev/lvm0/ovz-snapshot

На ALS 4.0.1 + Updates 4.0 такое работает с момента появления ALS 4.0.0.
Самба работает внутри ovz-контейнера.
На самом деле томов lvm больше. Они тоже бэкапятся по вышеприведенной схеме.

Как вариант, из-за высокой дисковой активности во время бэкапа, в коде самбы не получается залочить файл locking.tdb и нет кода проверки на получение блокировки. И в файл начинают писать два процесса одновременно.

Почитал блог.

Раздел мотнируется так:

/etc/fstab
/dev/lvm0/ovz   /var/lib/vz     ext3    defaults,data=journal           0 2

#mount
/dev/mapper/lvm0-ovz on /var/lib/vz type ext3 (rw,data=journal)

Почитал блог.

Раздел монтируется так:

/etc/fstab
/dev/lvm0/ovz   /var/lib/vz     ext3    defaults,data=journal           0 2

#mount
/dev/mapper/lvm0-ovz on /var/lib/vz type ext3 (rw,data=journal)

Я предполагаю, что это ошибка во взаимодействии simfs и ext3 с lvm. Самба пытается гарантировать осмысленность locking.tdb при записи, а создание снапшота в lvm, видимо, не синхронизировано с ext3/simfs -- в результате не всегда корректно сбрасываются буфера и содержимое отдельных инодов теряется. Высокая нагрузка на дисковую подсистему как раз может провоцировать это поведение.

В данном случае проблема не в блокировках как таковых, а в том, что прочитанное с диска состояние записи в locking.tdb не соответствует ожидавшемуся.

> Отловить причину не получается. Буду рад любой помощи.

Читали ли Вы данный thread?
http://lists.samba.org/archive/samba/2007-August/134395.html

Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd нужно писать и читать из locking.tdb и информация в нем должна быть корректной. Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb, это критическая ситуация для smbd и она обрабатывается должным образом.

Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.

(В ответ на комментарий №7)
> Приведенная ссылка не имеет отношения к нашему случаю в том смысле, что это не
> smbstatus, а smbd, который не открывает locking.tdb в read-only. Напротив, smbd
> нужно писать и читать из locking.tdb и информация в нем должна быть корректной.
> Поэтому, когда некорректное сбрасывание буферов или отсутствие синхронизации
> при выполнении снапшота вызывает повреждение содержимого в файле locking.tdb,
> это критическая ситуация для smbd и она обрабатывается должным образом.
> 
> Как уже было показано, переезд на ovz-rhel с теми же контейнерами проблему
А при переезде содержимое locking.tdb сохраняется?

> устраняет. Это значит, что ошибка в ядре -- в ovz/lvm или других частях.

locking.tdb -- это временная база данных, которая обнуляется при перезапуске smbd. Поскольку "переезд" на ovz-rhel -- это смена ядра, то ответ очевиден.

Насколько я понял Алексея, при повторении процедуры из комментария #2 в случае ovz-rhel порчи данных не происходит. Процедура выполняется по-живому -- при работающем контейнере.

Из обсуждения видно, что ошибки в samba (тем более в Сизифной) нет. Если это не так - просьба переоткрыть баг (с возможным перевешиванием на ядро).