+1
So, easy question, what are the requirements for the Live Browse feature?
Specifically, does the live browse only work on virtual machines? Is this NOT for physical or agent based backups?
(Sorry, searched around and didn’t quite find the answer to the actual requirements/limitations - as some of us do still have physical servers that we back up...)
Best answer by christopherlecky
View original
+16
Live browse is only necessary for non indexed content.
when you are live browsing a vm what is actually happening is that the vm volume metadata is being reconstructed in something approaching real time so you can “see into” a volume.
it simply isn’t necessary for data that is not abstracted away via some intermediate layer, such as a vmdk. iiRc you don’t even need live browse if you specify indexing your vms post backup.
Doing so is a heavy process though and adds significant time post backup.
typically not worth it to index every vm when it’s highly unlikely that you will need the index data for the vast majority of vms.
+1
thanks for you response…
I guess my real question is… is live browse available for a physical (or agent-based) server/client? Or is it only for VM’s?
+16
You don’t need live browse for most agent based backups.
I think you may be confused by the name. Live browse does not look at the current running vm data.
what it does is look into the contents of backed up data.
for most agents, file systems and such that information is housed in the index, so you when you a browsing for a restore, you are really just looking through the index.
for non indexed data such as vms, live browse is necessary because otherwise your own only option for getting file information would be to restore the entire disk.
+16
Think about it this way.
When you backup a file system the process looks something like this:
Discovery → Index → Backup.
For a file system , the discovery finds all the files and their metadata, writes their information to the index then backs it up.
For a vm backup, the discovery finds all the VMs’ and their metadata, writes their information to the index then backs it up.
In the case of the VM backup the index only has information about the VM’s, it doesn’t have a clue what it is in the VM.
So when you go to do a restore the process is as follows:
Browse the index for the data you want to restore→ Select the data you want to restore → Restore the data.
In the case of a VM restore the index you are browsing does not have any information about the file systems within the VM by default. What a live browse does is a pseudo restore of the volume that you look through, you are not browsing an index rather you are browsing the filesystem of the backup.
I hope that makes it clear.
The reason why I cannot answer definitively about agents, is because something like this or something analogous to this happens with any backup where you are not indexing the contents of the backup at the time of the backup.
For many of these agents there is the option to turn on post backup indexing but this has pros and cons.
+1
Got it, thanks!
Yes, at first I was thinking this was only for VM’s, but yes, it’s part of the indexing that takes place on (practically) every job (unless you’ve excluded it from indexing for some strange reason).
Anyway, found out that the DBA was doing a out-of-place (DB) restore and was doing a “live browse” to locate the proper place (G:\Restores) to put the file and the file browsing was throwing an error.
I had to tweak his permissions (in the Roles) to allow/grant “Live Browse” functionality.
(At first, I thought he was doing a “Live Browse” to view the contents of the backup.)
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
