Good news for Windows Server 2016 deduplication users, but bad news for all NTFS users. Microsoft has finally nailed that phantom data corruption bug that I talked about here before. We actually had quite an exceptional experience working with Windows dedupe team on this bug – they were treating one extremely seriously from the start, and it was one of those rare cases when they pushed us for updates - and not the other way around. So it made me smile when in the end, it appeared that the bug was not even in the dedupe engine, but rather in the NTFS sparse files implementation. As such, Windows dedupe gets to keep its name clean – however, the update is strongly recommend that all NTFS users, and will be included in August "Patch Tuesday". And most importantly – anyone with "Volume bitmap is incorrect" chkdsk error on your NTFS backup repositories, be sure to perform an Active Full backup after installing this patch, because you current backups may not be good. And apply the same logic to any other data that uses Windows dedupe or sparse files (create a new instance of the data).
Along with this data corruption bug, you will notice that the same KB4025334 includes a few issues around ReFS too. Particularly interesting ones, which must have been reported by Veeam users by the sound of it, are "performance issues in ReFS when backing up many terabytes of data" as well as "stuck thread in ReFS might cause memory corruption", so the update is definitely worth installing. Besides, there are a couple of confirmations on the forum that the fix does make a big difference. Unfortunately, we also already know that this KB does not include one more important ReFS fix that is still being backported to the current branch. And I know this one fixes the issue that ReFS dev team has been researching with one of the Veeam users. Bottom line – ReFS is getting there, but there are still known issues left for the future updates. In any case, overall these are all great news which shows that Microsoft does take ReFS issues seriously.
Also last week, VMware has published the new KB article about vSphere 6.5 PSOD which is actually quite easy to run into by simply disabling IPv6 on your hosts. I can see quite a few people potentially running into this because many of us like disabling those "unnecessary" things. Well, for now be sure to keep IPv6 enabled on all ESXi 6.5 hosts > KB2150794
Here is an absolutely fascinating number from a POC with one of our prospects. They've been testing Instant VM Recovery scalability, and ended up running 281 VMs from the backup! Now, of course those instant restores were PowerShell scripted, otherwise there would be too much clicking involved... and I assume the instantly recovered VMs were light on the load too – because VM startup was taking less than 1 minute per VM up until the end. Still, this is an extremely impressive result – I don't believe we pushed IR engine this far internally, primarily because achieving anything like this has two critical dependencies. First, their backup storage is a beast designed according to my earlier recommendations (big fat Cisco S3260 with a few SSDs dedicated to vPower NFS cache). Second, getting there absolutely requires version 9.5, where our developers have put an incredible amount of effort optimizing and accelerating vPower NFS to improve its scalability by an order of magnitude. And I do know they did not have enough time to include some final touches – so there's even more improvement to look forward to in v10!
And the last thing for today - be sure not to miss the largest free Microsoft eBook giveaway in the history (here's a PowerShell script to download them all). This is amazing! Thanks to Veeam Vanguard Rhys Hammond for sharing this with me, so that I could in turn share with you all. |
Komentáře
Okomentovat