Monthly Archives: November 2014
I know, I didn’t leave much to the imagination with the blog title and as you may of guessed I’m going to be attending Virtualization Field Day 4 in Austin, Texas this January!
I was ecstatic when I received the invitation and it didn’t take much convincing to get me to go! I’ve been a huge fan and supporter of the Tech Field Day format over the years, and not too many of them go by where I don’t catch a few session on the livestream. The fact that Austin is on average 30 degrees Celsius warmer than here in January sure does help too!
Aside from the heat I’m definitely looking forward to being a part of VFD4. This will be the fourth installment of Virtualization Field Day and it takes place January 14th through the 16th in Austin, Texas. The Tech Field Day events bring vendors and bloggers/thought leaders together in a presentation/discussion style room to talk everything and anything about given products or solutions. I’ll point you to techfieldday.com to get a way better explanation about the layout of the events.
This will be my first time as a delegate and I’m feeling very humbled for having been selected. Honestly I get to sit alongside some of the brightest minds that I know. Thus far Amit Panchel (@AmitPanchal76), Amy Manley (@WyrdGirl), James Green (@JDGreen), Julian Wood (@Julian_Wood), Justin Warren (@JPWarren), and Marco Broeken (@MBroeken) have all been confirmed as delegates with more to be announced as time ticks on. Some of these people I’ve met before, some I know strictly from Twitter and others I haven’t met at all so I’m excited to catch up with some people as well as meet some new people.
So far there have been 6 sponsors sign up for #VFD4 – Platform9, Scale Computing, Simplivity, Solarwinds, StorMagic and VMTurbo. Just as with the delegates some of these companies I know a lot about, some I know a little, and others I certainly need to read up on. Having seen many, and I mean many vendor presentations in my lifetime I have tremendous respect for those that sponsor and present at Tech Field Day. The sessions tend to be very technical, very interactive, and very informative – three traits that I believe make a presentation. I’m really looking forward to seeing my fellow Toronto VMUG Co-Leader and friend Eric Wright (@discoposse) sitting on the other side of the table 🙂
Be sure to follow along via Twitter by watching the #VFD4 hashtag leading up to and during the event. Also a livestream will be setup so you too can watch as it all goes down.
I’m so grateful to everyone for getting this opportunity – so thank you to my peers, the readers of this blog, Stephen Foskett and all the organizers of all the great Tech Field Days and the virtualization community in general – See you in Texas!
Unfortunately I had to learn this one the hard way – but in hopes that you don’t have to, here’s the gist of my situation. I’ve had Veeam running and backing up utilizing a Windows Server 2012 R2 box as a target for a while now! I’m getting some awesome dedup ratios utilizing both Veeam and Windows built in deduplication. That said, just last week I began to see this error occurring on one of my backups jobs.
“The requested operation could not be completed due to a file system limitation. Failed to write data to the file [path_to_backup_file]”
After a bit of Google Fu one can conclude that from here and here my problems were mainly due to the way my volumes were formatted – more specifically the support of for large file records. I, like most people went ahead and simply used the GUI to format and label all of my volumes. The problem being, utilizing the GUI also utilizes the default settings for the format operation, which in turn support only small size file records.
Therefore, after time, after some data is laid down to the disk, after dedup has been doing it’s thing for a while you might start to see the same error I was. The solution – well, unfortunately it is to reformat that volume with large size file records. The command to do so, pretty simple, listed below
Format <DRIVE> /NTFS /L
The key here being /L, which specifies the support for large size file records. Also, this process can take quite some time. From the time I ran the command to the time I had to get to this point in this blog I’m still sitting at 2%.
In my case, I removed all the backups from Veeam that lived on this disk. I’m comfortable that I also have replication running so I wasn’t worried about losing any data. If you are though, you could always simple disable dedup and copy your backups files to another location, run the format command and then copy them back. Honestly, I knew in my case it would be easier and quicker to simply just reseed those VMs.
Also, it’s not to say that Veeam won’t work without large size file records. I have 8 other volumes on this Veeam instance which have all been formatted with the same default settings and haven’t seen any issues whatsoever with them – just this one volume is throwing the error! For now, I plan on just leaving these other volumes the way they are. Am I just delaying the inevitable? Only time will tell!
Thanks for reading!