Linux.by

все просто - делаю я бэкапы при помощи тара, способом вида tar -cf /mnt/remote_backup_storage/root_vlume.tar /mnt/root_volume_snapshot
ну всмысле я LVM юзаю так что вроде это вполне надежно, да?

но фишка не в этом. фишка в том, как получить этот самый /mnt/remote_backup_storage/ примонтированным, принципиально не хочу ходить по серверной с винтом, хочу сидеть "откинувшись на спинку кресла" и запускать скрипты которые все будут делать за меня, да вот не судьба кажется.

окружение таково:
везде дженту с самосборным ядром.

сервак с которого сливается бэкап, он же клиент для бэкап сервера таков:
1.LVM root
2.reiserfs partitions

про сервак для бэкапов в свою очередь можно сказать тоже самое + сам бэкап производится на USB винт с reiserfs(обычный партишн, не часть LVM)с перспективой помещения в физический сейф.

способы экспорта были перепробываны следующие(в хронологическом):

1.очевидный - NFS. 5 стремных демонов которые неработают без объяснения причин. очень долго читал мануалы, очень много всего перепробывал. иногда пробивает, но от чего это зависит уловить так и не получилось. последняя ошибка can't read superblock. далеко не первый неудачный половой опыт с этой штукой. последнее время становлюсь склонен ругатся на NFS в принципе.

2.samba - все хорошо, но лимит на размер файла не дает перелить весь партишн. можно его снять?

3.nbd - просто вылетает. качает-качает и вдруг просто перестает. оставляет после себя мертвые устройства и маунтпоинты. хотя в принципе своем прога мне бешено понравилась в своей идее. проще и логичнее некуда, но неработает. оч жаль. пробывал менять размер блока и MTU - таже фигня.

4.sshfs - тоже полезная своей секьюрьностью и гибкостью технология. симптомы те же, просто молча обрывается оставляя все что с ней работает в зависшем состоянии. и это и предыдущее где-то примерно на втором гигабайте. как и самба.

может есть что пятое, или будут у кого догадки касаемо предыдущих 4х?

1. NFS - рекомендуется использовать nfs-kernel-sever и не суваться в nfs-user-server. Первый (в отличие от второго) - работает. Второй - работает через жопу и тысячу лет уже как не поддерживается.

Описанные тобой ошибки весьма странны и у меня в production на nfs-kernel-sever не появлялись, хотя в двух конторах, в которых я имел счастье работать, NFS используется весьма и весьма интенсивно.

2. за самбой не следил последние полтора-два года, отстал от жизни.

3. nbd - неподдерживаемый глючный мутант, в топку.

5. Настоятельно рекомендую посмотреть в сторону iSCSI. Те же идеи, что и в nbd - отдавать блочное устройство, а клиент сам решает что с ним делать.
http://iscsitarget.sourceforge.net/ - свободная имплементация сервера (таргет в терминах iSCSI), open-iscsi - свободная реализация клиента (инициатор в терминах iSCSI).

1.что-то я запутался. если заинсталлил nfs-tools, то это получается уже юзерспейс? запустилось5 демонов, значит логично предположить что это очень даже юзерспейс? а как тогда в ядерном режиме? честноговоря я вообще не представляю себе сервер работающий полностью в ядре. а как его перезапускать тогда, вместе с системой чтоли? всеравно какая-то обертка должна быть. вобщем с того момента когда я последний раз читал мануалы оно у меня снова все в башке запуталось. кажется везде описывается только один какой-то вариант, причем не факт что кернел. как мне однозначно узнать что это кернел вариант либо нет, и что прочитать чтобы это был кренел вариант? у меня создалось впечатление что гуглятся доки легко, да какие-то не те.

5.спасибо, интересно. ща посмотрю.

nfs-utils - это nfs-kernel-server

iSCSI-ініцыятар ужо ёсць built-in у Linux kernel 2.6.21

mend0za, почему тогда такие проблемы?
я замечал что это зависит сильно от сетевушки, может в ней дело?

возможно проблемы в вашей сборке системы
использовавашиеся мною машины - это были в основном Debian/Alt Linux, с ядрами по умолчанию, релизы (не снапшоты)

сетевые в основном Realtek (8139) и бюджетные интелы.

http://xgu.ru/wiki/ATA_over_Ethernet подойдет для поставленной задачи?