LINUX.ORG.RU
ФорумAdmin

«хитрое» резервирование. как сделать?

 , , ,


0

1

Добрый день, комрады.

Подскажите пожалуйста мне за резервирование.

Нужно производить резервирование n-серверов на сервер резервирования. Все сугубо linux. Хостинг провайдер дал в распоряжение n-количество NFS шар. Узел резервирования монтирует эти nfs шары.

Проблематика: nfs шары от провайдера даются as-is и менять что то он по моей просьбе не станет. Все файлы которые попадают на эти шары меняют uid на 100. Получается, что n-серверов для того чтобы сложить туда свои бэкапы не могут пользоваться различными учетными данными дабы как то разграничить между собой права. Samba на сервере резервирования с шарами внутри смотированных nfs директорий выдают ошибку доступа (оно так и ожидалось, решил просто попробовать «ну а вдруг» как говорится). NFS over NFS - т.е. поднять на сервере резервирования свой NFS и в exports прописать каталоги внутри провайдерских nfs шар как свои локальные nfs шары дабы разграничить доступы - permission denied при попытке монтирования. Т.е. либо это невозможно, либо я что то неправильно готовлю.

sshfs через ключ пользователя который имеет право туда писать - done. НО! этот пользователь на всех серверах будет один. Получается, если один из узлов будет скомпрометирован, то через него можно поиметь все бэкапы весьма нехитро.

Пробовал обратный sshfs - активная схема: сам бэкапер монтирует свой определенный каталог в нужный каталог клиента и кладет условный файлик являющийся неким trigger-file наличие которого позволяет клиенту начать писать данные в этот каталог.

Оно работает, НО клиент в такой схеме даже не подозревает что у него что то там смонтировано и пишет данные в этот каталог переполняя свою собственную локальную FS. Для резервирования объемов данных > чем свободное место в локальной FS даже при наличии сжатия бэкап зафэйлится. А у меня 90% таких случаев.

Собственно вопрос: не подскажете ли, что мне использовать для активной схемы резервирования чтобы избежать вышеуказанной проблемы переполнения локальной FS?

Заранее спасибо.



Последнее исправление: nickdsl (всего исправлений: 4)

Репозиторий restic на той NFS. И шифрование, и конкурентный доступ, и дедупликация.

anonymous
()
Ответ на: комментарий от anonymous

А можно чуть-чуть подбробнее?

Либо я что то не до конца понимаю, либо Вы, возможно, не до конца поняли суть моих мыслей.

sNFS - NFSaaS (as a service) - провайдерская. Монтируется для определенного ip и все файлы там складируются либо рутом либо локальным пользователем с uid=100 и на этой шаре uid меняется на 100.

Про какой NFS Вы имели ввиду? Про локальный NFS сервер? Как я писал: NFS over NFS? У меня это не взвелось. Вернее не смонтировалось. Так можно?

Про шифрование - если учитывать то, что доступы пока не удается разграничить, то шифрование лишь наполовину решает проблему - не украсть данные, НО удалить то их можно. Это тоже очень плохо.

nickdsl
() автор топика
Ответ на: А можно чуть-чуть подбробнее? от nickdsl

Про какой NFS Вы имели ввиду?

Провайдерский. На UID плевать, покуда можешь писать/читать.

НО удалить то их можно

Пока это на железе провайдера, такая возможность будет всегда. Очевидно, что нужна копия где-нибудь «у себя».

anonymous
()
Ответ на: комментарий от anonymous

Про uid.

Точно ли плевать на uid? Внесу немного деталей. Среди серверов резервирования есть postgresql. Дамп выполняется от имени postgres через pg_dump. Когда раньше делал это по samba, то приходилось монтировать с опцией смены uid для шары на postgres.

Тут же, как мне кажется, так уже не сделать. Верно?

По поводу удалить: согласен. Но при разделенной схеме резервирования можно удалить только бэкап для текущего одного скомпрометированного сервера за текущий день (если бэкап уже был сделать). Бэкапы других серверов и за прошедшие дни уже удалить невозможно т.к. они находятся за пределами точки монтирования для текущего однодневного бэкапа.

Вот в чем фокус.

nickdsl
() автор топика
Ответ на: комментарий от anc

Я пробовал создавать юзера под sshfs.

Он может выйти за границы хоума и грохнуть все что там есть на nfs шаре.

nickdsl
() автор топика

Про nfs over nfs

Нашел подтверждение на англоязычных ресурсах, что это не работает. Т.к. философия nfs в том, что он гарантирует, что шара которую он экспортит это 100% локальное «физическое» устройство, а не что либо пророшенное еще откуда то там.

nickdsl
() автор топика
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

restic и есть бэкап с шифрованием, куда уж проще.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.