Комментарии 5
Отличная статья, спасибо!
А какой максимальный размер файла tibx, Вы наблюдали?
Если дедупликация делается на агенте, а в случае бэкапа платформы VMware может одновременно использоваться несколько виртуальных эплаинсов, то каждый эплаинс будет создавать свой tibx, или он будет один на план РК? И если второе, то дедуп будет глобальный для этого плана или каждый эплаинс будет дедупить только те данные, что он через себя пропускает?
1) Самый большой архив который видел в заявках клиентов был чуть больше 30 ТБ. Проблем с ним не было, просто видел его в логах. Но уверен что есть и поболее.
2) Привязка архива для ВМ идет по ID этой ВМ и ID плана. По этому в момент начала резервного копирования происходит балансировка по агентам (кому удобнее и проще), а потом агент продолжает созданный ранее архив. К агенту тут архив не привязывается.
3) Дедуп в данном случае будет в рамках последней цепочки (полная копия и ее дифы + инкременты).
>Привязка архива для ВМ идет по ID этой ВМ и ID плана. По этому в момент начала резервного копирования происходит балансировка по агентам (кому удобнее и проще), а потом агент продолжает созданный ранее архив. К агенту тут архив не привязывается.
То есть на план РК один архив? и агенты друг с другом и узлом хранения хешами обмениваются?
Как я понял - внутри tibx это Full и множество инкрементов. эту цепочку рекомендуется делать не более чем в 100 точек. Но в таком случае, пусть через 100 бэкапов, но мы вынуждены будем начать новую цепочку. и соответственно на бэкэнде мы должны предусмотреть место для облеих цепочек. А может этот tibx использоваться с реверсивным инкрементом? В таком случае вторая цепочка не понадобится...
Tibx или не tib(x): вот в чем вопрос…