OU
Лайфхак это не менять имя ресурса 😄
Size: a a a
2021 September 18
D
Я уже думал отдельно DNS прописать имя для репо
OU
Думай до следующей смены
D
Veeam agent for Linux крайний debian поддерживает ? Что-то у меня ставится не хочет
OU
Кто что поддерживает есть на сайте вима
S
2021 September 20
VK
THE WORD FROM GOSTEV
While it goes without saying that you should not update your ReFS backup repositories to Windows Server 2022 before we deliver its official support with version 11a, there are always people who feel adventurous or just like to experiment. If you're one of those, please do stick to clean Windows Server 2022 installs for now, as there's the confirmed regression in the ReFS format upgrade code path which may leave your backup repository in the BSOD boot loop.
LTO-9 is now generally available, increasing native media capacity to 18TB and bringing 400 MB/s transfer rates! I still remember how 5 years ago I was writing here about Barium Ferrite (BaFe) tapes being on the horizon – well, we've reached that horizon! Aside from increased density this technology apparently improves reliability: BaFe LTO-9 tapes are rated to maintain stable magnetic characteristics for over 50 years! This is exciting and all, but when will Veeam Backup & Replication support LTO-9? While we fully prepared V11 for LTO-9 based on tech preview hardware testing IBM has arranged for us in October 2020, now that we tested the commercially available hardware we discovered one significant change: a new requirement to initialize new LTO-9 tape media prior to use, which was not there in our preliminary testing. Further, was saw this process taking anywhere from 20 to 120 minutes, making our tape jobs fail due to exceeding timeouts. And unfortunately the issue came too late for us to address in V11a, which is already in the Release Candidate stage. So now, our plan is to release a hot fix for V11a to prevent jobs from failing, and then add some proper integration with this new tape initialization process in V12.
Some of you may know we have this thing called Block Generation for our immutable backups feature on object storage. While it was always nothing but under-the-hood optimization for API costs which "shall not be named", unfortunately it got documented [and not in a very clear way] in the User Guide, making many people unnecessarily aware but also severely confused. As a result, we're seeing more and more cases where people who think they understand how it works make their product deployment decisions with this optimization in mind, counting these extra days towards the total Immutability time and therefore setting wrong values in the UI (lower than it is actually required). Classic "Woe from Wit" case! My best advice is to just forget this optimization exists and set your immutability settings according to the actual business needs. Nevertheless, the documentation has also been reworked since to more clearly explain how it works.
A few week ago I shared that we declared official support for HPE Alletra 9000 (Primera OS based) but still waiting to test HPE Alletra 6000 (Nimble OS based). Today, I'm happy to announce that we completed the testing and are announcing support for the Alletra 6000 immediately with all the same storage snapshot integration features as for Nimble arrays. Kudos to HPE for ensuring no API calls we use broke! Until the backup console UI has been updated in V12, you should register Alletra 6000 arrays as HPE Nimble storage. By the way, here's an excellent new support KB article that tracks ALL of our many primary storage integrations along with features supported for each specific storage > KB4206
While it goes without saying that you should not update your ReFS backup repositories to Windows Server 2022 before we deliver its official support with version 11a, there are always people who feel adventurous or just like to experiment. If you're one of those, please do stick to clean Windows Server 2022 installs for now, as there's the confirmed regression in the ReFS format upgrade code path which may leave your backup repository in the BSOD boot loop.
LTO-9 is now generally available, increasing native media capacity to 18TB and bringing 400 MB/s transfer rates! I still remember how 5 years ago I was writing here about Barium Ferrite (BaFe) tapes being on the horizon – well, we've reached that horizon! Aside from increased density this technology apparently improves reliability: BaFe LTO-9 tapes are rated to maintain stable magnetic characteristics for over 50 years! This is exciting and all, but when will Veeam Backup & Replication support LTO-9? While we fully prepared V11 for LTO-9 based on tech preview hardware testing IBM has arranged for us in October 2020, now that we tested the commercially available hardware we discovered one significant change: a new requirement to initialize new LTO-9 tape media prior to use, which was not there in our preliminary testing. Further, was saw this process taking anywhere from 20 to 120 minutes, making our tape jobs fail due to exceeding timeouts. And unfortunately the issue came too late for us to address in V11a, which is already in the Release Candidate stage. So now, our plan is to release a hot fix for V11a to prevent jobs from failing, and then add some proper integration with this new tape initialization process in V12.
Some of you may know we have this thing called Block Generation for our immutable backups feature on object storage. While it was always nothing but under-the-hood optimization for API costs which "shall not be named", unfortunately it got documented [and not in a very clear way] in the User Guide, making many people unnecessarily aware but also severely confused. As a result, we're seeing more and more cases where people who think they understand how it works make their product deployment decisions with this optimization in mind, counting these extra days towards the total Immutability time and therefore setting wrong values in the UI (lower than it is actually required). Classic "Woe from Wit" case! My best advice is to just forget this optimization exists and set your immutability settings according to the actual business needs. Nevertheless, the documentation has also been reworked since to more clearly explain how it works.
A few week ago I shared that we declared official support for HPE Alletra 9000 (Primera OS based) but still waiting to test HPE Alletra 6000 (Nimble OS based). Today, I'm happy to announce that we completed the testing and are announcing support for the Alletra 6000 immediately with all the same storage snapshot integration features as for Nimble arrays. Kudos to HPE for ensuring no API calls we use broke! Until the backup console UI has been updated in V12, you should register Alletra 6000 arrays as HPE Nimble storage. By the way, here's an excellent new support KB article that tracks ALL of our many primary storage integrations along with features supported for each specific storage > KB4206
D
Подскажите, надо делать бекап расшаренной папки с контроллера домена под windows 2008R2 - в veeam лучше его добавить как SMB шару или как windows server ?
АГ
2008 вы вимом вроде уже не забекапите
АГ
Как шару бекапьте и все
D
Он весь бекапится удачно вместе с exchange, вопрос возник в дополнительном более частом бекапе в другой репозиторий
D
Пытаюсь добавить - нужную папку раскрыть не может, просто показывает что в ней подпапок -нет. Соседние папки раскрывает до конца - куда копать ?
D
Как SMB шару - добавил нормально.
АГ
D
Использовал одинаково полные
D
Может действительно 2008R2 не нравится
АГ
АС
Ну ради бреда, попробуйте переименовать её или рядом создайте с похожим названием