So go ahead and get root access to the SDDC Manager and create a file called feature.properties within the /home/vcf directory. So there you go – you actually have to enable the backup schedule. After some perusing of release notes and slacking I found this valuable bullet point: Sure, I had no problem actually setting up my backup locations, and triggering the backups manually did indeed result in backup files on my SFTP server – but the schedule never ever did kick in. After many attempts, which will return a successful HTTP response, I realized that this just was not working.
Veeam file level restore Patch#
The documentation simply outlined the process of sending PUT and PATCH requests to the backup endpoints to set up the schedule. This is one of the parts that threw me for a loop. Next, the ability to use the backup schedule needs to be enabled. I simply just spun one up on an Ubuntu machine, and then set Rubrik up to scrape the SFTP root folder with a Fileset, which ensures I’m actually getting the backup data into a secondary, immutable location. While other VMware products such as NSX/vCenter support their file-based backups over protocols like NFS/SMB, SDDC Manager, as it currently sits, is only SFTP. The API documentation, while improving, still lacks a few key pieces of information that you need to do in order to begin scheduling file-based backups of SDDC Manager – with that said, let me lay out the process here for you! First things first, SFTP!īefore getting too far just know that this whole process requires an SFTP server to host the backups. This last go around I’ve been doing a bit of testing around using the VMware Cloud Foundation File-Based backup API. Throughout these projects, I’ve seen quite a few changes (for the better) with the VCF APIs. I'm a big fan of Veeam, but I believe simple file level recovery, with permissions in tact, should be a core functionality of any backup software.Over the past year or so I’ve been part of a couple different projects within Rubrik which involved completely destroying and rebuilding VCF’s Management Domain. Whether it's a deletion of a file or a corruption, single file level restore is a primary role in any backup product. In my opinion, this is a huge downfall to the product because 9 times out of 10 the only kind of restores administrators normally do are retrieving files from a user's mistake. This is a temporary work around and I expect that this will be in the GUI for the next release. In this case I chose the Veeam desktop, and verify the permissions were the same on both ends.
Now we can Restore guest Files (Windows) and choose our date.ĭrill Down to our file and take a look at the permissions on this exact fileĬopy the file to our destination. Right Click -> New -> DWORD (32-bit) Value.HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication.So, we decided to hide this in the registry instead. But, because it was implemented very late in the release cycle, we did not have time to add it in UI.
Veeam file level restore windows#
Per Kendrick, this totally escaped my head due to the pre-release rush, but thinking more about this I now remember that I did bring this up with development earlier already, and they did implement the option to preserve permissions for Windows restore. This issue has come up in Veeam support before, so luckily there is a hidden registry setting within Veeam v5. As told by in my forum post: Indeed, it looks like Microsoft had removed this registry setting in Windows 2008 R2. This seems to be a problem with Windows Server 2008 because it won't even inherit the folders permissions when copied over. The permissions were still not being kept.
I rebooted the Veeam server, re-started the process over and tried moving it from the Windows Explorer window. # On the Edit menu, click Add Value, and then add the following registry value: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer # Locate and then click the following registry key: But this fix only applies to Windows 2003 and XP. I did some research and saw this Veeam Forum post using the Microsoft KB article here. I noticed that the permissions weren't being copied over. 2 minutes later I get an angry email about the file being READ-ONLY and how this should never happen, blah blah blah. I fire up Veeam B&R, drill down to the file, browse to the folder and replace the deleted file. After having Veeam running for 8 days, we finally got a ticket that said we needed to restore a file back on our file share server. I upgraded to Veeam v5 in hopes that one little tid-bit would be fixed, File Level Restore (FLR).Ĭurrently, our company's veeam backup server runs on a Windows Server 2008 R2 VM. We all know and love Veeam because it truly is an innovative product with lots of great features.