5 easy sessions: Advanced Deployment and Configuration - Whiteboard Fridays

live from the bee studio in Atlanta Georgia this is bean whiteboard Fridays starring your host the manager of the inside engineering team mr. Jose Mendoza alongside the trusty panel of senior engineers Jason Leyva and Sean Luke remember keep the show interactive with your comments and questions now sit back relax and enjoy the show enjoy the show that's right welcome everyone once again to episode number two of my poor Friday's the five series that we've got going on let me turn the music down here a little bit good to be back I'm your host Jose Mendoza you see the name of there on the screen so hopefully you know who I am by now but anyway it's great to have you back as always we have Jason and Sean who we're going to meet here in a few moments before that I just want to remind you real quick and I'm going to pull it up these are the beautiful backpack that we're giving away for this series so please ask questions keep it interact that keep it fun and hopefully you'll get to win one of these very cool backpacks but don't feel bad if you don't because we are giving away other other prizes as well we've got a USB 8 gig USB thumb drive that were given away no Pat's and a couple of other things as well so before we get started I'm going to turn it over to our panel with Jason and Sean and they're gonna tell us what we've got in store for episode two today so let's go ahead and meet these guys here Jose so today we are we looking at distributed architecture for Veen backup and replication version 6.5 so we're going to show you a lot Jeff a live demonstration of how to deploy distribute architecture components both Sean I will be going on the whiteboard and kind of drawing out some of how that actually lays out in your infrastructure and how you can deploy those in different manners to to get the most efficient usage of your backup infrastructure Sean yeah so I'm going to go to the whiteboard initially and talk about the actual architecture itself give you some best practices some of the different options that you have when you're considering deploying the different components within the Vemma Kotecha excellent guys appreciate that very much and what I'm going to do is just throw the agenda up on the screen and trying to think you are going to have to change your battery if you don't mind it I'm getting a lot of feedback on there so go ahead and do that but in the meantime what we'll do is what Shawn gets that up there real quick I'll bring it back here to do myself but look at the agenda again this show is a lot more fun when we keep it interactive now for those that can't make it in today there will be a recorded version so if you don't get to stay the entire time or if you miss it then you can come back in next week in you know play it back so after the show is done we will upload it to the website again that's Viacom slash whiteboard if you've registered you should know where that is already so I would suggest that you visit if you haven't and register so what we'll do is we're going to turn it over to Shawn over on the whiteboard and he's going to go ahead and talk to us about today's episode but again keep it fun keep it interactive and welcome once again so let's go Shawn go to shown on the whiteboard I just want to make note if everybody just takes notice of this that I'm just going to use the letter B for the backup server the letter P for the proxy and the letter read for the repository so I'll be using that throughout my whiteboarding session just just to make it a little bit more streamline here so just for reference there so what I have behind me is our basic architecture that I like to use just simply three hosts V Center management server and some storage via same you'll notice that the Veen backup server here is already deployed so one of the most popular questions that we get when deploying theme inside the environment is should I go physical or should I go virtual machine route for the Veen backup server itself right so there's pros and cons to each to each type right with a physical server the nice thing about the physical server is that it is outside of the cluster that is protecting right so it's going to give you the best protection possible some things to consider there right some of the cons is one cost right you do have to have a dedicated physical server for the beam server number two there's some considerations to take in there right with a physical server to achieve a land free back up you will have to have access to your sand fabric right the proxy component will that allows you to leverage the directs an access mode and read data directly from the sand right without having to go across your network so that requires an HB a or I scuzzy connection into your sand fabric all right so just some things to consider there for the physical server route the virtual machine route right nice thing about the virtual machine route is the configuration is very easy there's nothing for you to actually do via automatically detects that it is a virtual machine automatically leverages virtual appliance mode for any volumes within that cluster and that's it right so it's very straightforward very easy to install very easy to deploy low cost all it's going to cost you as a Windows license right so that being said the con of a virtual machine is if you lose your cluster you've just lost your ravine backup server it's not a huge con because you can install a beam on any windows-based machine very easy takes roughly 10 or 15 minutes to get it installed veem automatically backs up is configuration data and Jason can show you that later when you when he's on the computer where that configuration data is actually stored by default you can send it to some location outside of the cluster so that you have your configuration data stored that way if you need to deploy beam backup and replication again you can simply just import the configuration and have all your jobs back in that that server so that that's not a huge con for being on a virtual machine but just some things to consider there right so now the VM backup application server itself there are some basic recommendations that we give just as far as CPU and memory resources allocated for the spacer ver right we do recommend that you have four cores and four gigs of RAM for the beam server whether it be a virtual machine or a physical server and that's because beam does sit on top of a sequel back in write sequel Express back in so it does require some some RAM there for sequel and the CPU requirements because VM does perform deduplication and compression in line write compressions heavy on CPU so that's the basis of that particular recommendation so next I want to talk about some considerations right um before we take a look at the different components and how we can split it out we got to take into consideration your jobs right how do you break out your jobs there's lots of flexibility within the bean backup job itself and you can add virtual machines individually into the job or you can actually add them by container I can add in an entire host I can add an entire cluster an entire datastore a specific folder of yams right so just some considerations there and some best practices right for the jobs you really don't want to exceed more than 8 terabytes worth of data in a single job and that's that that's that that's on the high side right we really like you to keep it somewhere around 4 terabytes worth of data in a single job and if you have a large virtual machine that's greater than 2 terabytes in size you probably want to put that virtual machine into its own job right this just ensures that you're going to get timely backups and that you're not going to have any huge backup files ok so now that we talked about some of the job considerations let's talk about some of the considerations when actually splitting the VM architecture out right it's actually a very good idea to have a mixture with your proxies right because with our distributed architecture the backup server actually serves as like a central administration console right it handles all of these scheduling of the jobs distribution of job duties to those proxies and then the proxy component itself does all the heavy lifting right it retrieves the VM data handles the compression the deduplication and then it passes the data off to the repository repository is simply just a disk based target where you wish to house your backup files we are completely storage agnostic on the repository side so you have a lot of flexibility there all we're really looking for is a disk based target to land on ok so before we talk about how to best break apart the architecture beam let's talk about the dataflow right how does the data actually flow and I'll draw the proxy here we're going to assume this proxy is a physical one and let's say I also have a virtual machine proxy so I can show you how the data flows in both scenarios so here in this scenario I have two proxies one's the physical ones of virtual proxy I'm going to assume that the physical proxy does have connectivity into the San fabric right we want to achieve the best possible performance so initially what's going to happen is the backup server is going to communicate to your vCenter server and it's number one number two vCenter is going to return the VM list so now the backup server knows where all of your VMs are located now another consideration here on the backup server itself is how many jobs are you trying to run concurrently right I have two proxies here let's say both my proxies have four cores allocated to them so both proxies are capable of running two jobs concurrently right because the rule of thumb for the Veen proxy is two CPUs per job right and that's Auto detected by beam and we will set the number of concurrent jobs based on that number you can increase the number to more than what's recommended however you will receive a warning and it may be a potential bottleneck in your backups okay so the next thing we want to keep in mind so since both have two cores I mean four cores both can process two jobs concurrently right so let's say I'm trying to run for jobs concurrently you remember my base recommendation of four gigs of RAM right that's a base recommendation okay so some things to take into consideration is how many jobs am I going to run concurrently if I'm going to run for jobs concurrently we do recommend that you give the avene backup server 512 Meg's per concurrent job the reason for this extra memory is because step 2 there these centers returning us a list of all of your virtual machines right each job has its own list so that does require additional RAM to hold that list in okay so just keep that in mind so as you scale out you will need to scale out the memory as well the RAM requirements there so now once we receive that VM list at the backup server the backup server is going to select the proxy based on not only availability but efficiency right which proxy can process that particular job the fastest right that particular virtual machine so initially it's going to hand the job off to the physical server because directs an access top of the list okay so the physical server is going to get the first two jobs right so what happens next is the physical server is going to the physical process is going to retrieve the data directly from the same right you can allocate those or the visibility into those volumes can be read only if you wish however keep in mind that veem does disable auto mount by default so that the Windows machine that we're installed on is not going to try and mount those volumes and format them okay so that's step three write the physical proxy will retrieve DVM data and then once it's done with its deduplication compression hands off the backup file into the repository which is step four where the backup file is finally store okay so now let's take a look at what happens when my third job runs right so the first two jobs are automatically going to go to the physical proxy because it can use the recs and access mode but now it's busy processing those first two jobs so job number three and job number four get handed off to the virtual proxy by the backup server and so now the virtual proxy is going to leverage virtual appliance mode essentially using VA DPS hot add capabilities it will leverage the host IO stack here right so it's going to retrieve data through the host i/o stack and then once it's finished with its compression deduplication pass it off to the repository okay so that's how that workflow looks when the proxy is both a physical and a virtual okay so just some things to keep in mind so now let's talk about how many proxies right that's one of the biggest questions that we get how many proxies do I need for my environment right the answer is it really does depend you can scale out proxies both vertically and horizontally right I can scale out vertically by giving the proxies more cores right two cores per job if I gave this proxy eight cores now it could process four jobs simultaneously instead of two right so you could also scale out horizontally by deploying more proxies right and that is completely up to you how you want to deploy it in your environment and depending on what resources you have available a couple of rule of thumbs there just just so you get a baseline of what you're going to need is if you're using the virtual proxy method with four V CPUs roughly a hundred beams with roughly ten terabytes of space used two jobs at roughly 50 megabits per second or 50 megabytes per second that's what you can expect to to process with that particular proxy right so with a physical proxy 16 cores let's say you have directs an access and you have 16 course you can run eight jobs concurrently assuming a processing rate of roughly 100 megabytes per second you can expect to process 400 VMs roughly 40 terabytes worth of data so you can use that as a baseline of course it is going to vary based on your environment and based on your actual processing speed but that's that that's just a nice baseline date to get started with so you can determine how many proxies you're actually going to need in your varmint okay so now let's talk about some considerations when we're taking a look at the repository right so now I'm scaling out proxies right I have more than one proxy I got a really take into consideration the what can be repository received right how fast can it receive that data just trying to eliminate certain bottlenecks so you can get the best performance possible some things to take into consideration with the repository is not only the ingestion rate itself but the i/o right IO is a big consideration with me and I'm going to explain why because depending on what type of spindles you have for that repository is going to dictate how much I owe it can actually handle okay and another thing that also depends on how much IO is generated by V is the actual backup mode itself okay so let's take a look at the two different backup modes that we offer within the beam solution and I'll talk a little bit about how much I owe each backup mode generates right so you can use that as a guideline as well into which job mode should I select for my mean backup jobs okay so the first and the default backup mode is the traditional incremental style backup mode okay let me illustrate what I mean so with the traditional incremental style backup mode the first thing you're going to start off with is a full backup right the F is for full backup okay on subsequent runs we're actually going to leverage change block tracking to help us identify all the change blocks without having to go and search for them and we're going to take those change blocks and write them out into standalone incremental files okay so I for incremental okay and we'll do that during the week right and on a specific day of the week which the default settings for Saturday you can choose any day you like so let's just say a Saturday what beam is going to do is we're going to create a synthetic full right and what the synthetic full consists of is essentially the incremental blocks for that day then we're going to pre-populate the remaining blocks of the synthetic full with this existing chain of incrementals and this full backup so now this becomes a full right the difference between a synthetic full and an active full is the way it's created right it looks feels smells just like an active fool the only difference is the way is created so the advantage of the citizen thetic fool is on average only requires roughly a third of the time to create right versus inactive fool because we're not pulling all new data however there is additional processing that takes place to create the synthetic full right so let's talk about IO in this specific scenario with the forward incremental each time the job runs for every single block there is only one IO it's just the right all we're doing is we're writing to the repository so all this IO talk that that I'm about to reference is strictly at the repository level right so one right to the repository per block that's it during the first full and the subsequent incrementals on Saturday when we create the synthetic fool we're going to have to read data and then write data right so there's actually three io per block when you're talking about synthetic full right so that's a significant amount of i/o if you consider a 7200 rpm SATA Drive can give you probably roughly around a hundred I oh we can saturate that pretty quickly right so just some things to keep in mind when you're taking a look at the repository and what backup mode you select because this can potentially be your bottleneck in your system especially if you have more proxies but don't just keep in mind the backup modes we at beam always stress the recovery aspect of things right how quick it is to recover with insulin VM recovery file our file level recovery wizards and our exchange Explorer so when you're going to perform those types of recoveries the performance of the repository is also going to make a difference as well right so the big advantage of the forward incremental is that it requires minimal IO during the week right only one day of the week which by default like I said set for Saturday it does it require more IO so your backups are going to go fast right it's just one IO / block so now let's take a look at the other backup mode that we offer which is the reversed incremental and I'm going to use a different color for reverse incremental so just like the forward incremental the first backup is going to be a full right like I said it's our baseline our starting point but on the next run instead of just taking a standalone file what we're going to do is we're actually going to push the full forward right how we do that is we actually take the change data for that day those change blocks and we just take those change blocks and we insert them into the fool okay what we're going to do then is we're going to take the blocks that those new blocks replaced and we're going to create a row back point with the old blocks and so the nice thing about the reverse decrement oh is that that fool just keeps moving forward along the chain and you'll just have a bunch of rollback points so big thing is you only have one fool ever right everything else is simply rollback points but at what cost and because we're injecting data and then we're writing the data out to rollback points there's going to be reused there's going to be writes right so three i/os per block on the reverse incremental every single day okay so that has to be taken into consideration when you're wanting performance right depends on what you want performance or space savings that's how you look at the two different backup modes right the reverse incremental only one full and a bunch of rollback points so you're really going to get a lot of space savings because I never have to create another full I just bunch of rollback points but it does come at the cost of more i/o so your jobs will take longer and now with the forward incremental it's one i/o during the week so the jobs perform really fast and only on one day of the week do I do that synthetic full but you notice I have a synthetic full right so and I still have my previous full so now I have multiple fools on disk at any given time so it does take up more storage space but it's going to be faster during the week okay so just some things to keep in mind when you're selecting the different job types and when you're choosing a specific repository for your backups right because if you're going to want to use the reverse incremental mode this is actually recommended only if you're going straight to a disk target and not going to be offloading it for any purpose okay one thing to also keep in mind is if you're going to select a deduplication appliance a physical deduplication vice - how's your backups the recommended approach is going to be forward incremental yeah and you do also want to turn compression off so just some things to keep in mind there other than that let's talk about space right how much space am I going to need on my repository okay so the amount of space of course is going to depend on what backup mode you actually select okay so you just want to know how often are you creating a full how many incrementals are you going to have right what kind of retention policy do you need so let's say I have a traditional incremental style backup and I want to keep two weeks worth of data on disk I'm only backing up once per day okay so your two weeks worth of data on disk means that the wave being prunes the data right I'm only gonna have fourteen restore points here if I'm doing once per day that's going to give me two weeks but I can potentially have up to three weeks with the backups on this because meme we cannot prune this full backup alone right we have to wait till the entire chain expires before we prune the data okay unlike reverse incremental where we can prune the data as needed because it's just rollback points right it's not dependent on the entire chain okay so that's another distinguishing factor between four and incremental and reverse incremental okay so I can potentially have three full backups right so I take that number of backups and I figure out what size they need on on actual disk right some things to take into consideration there is our overall compression and deduplication ratio we do like to use two to one it is a guesstimate it's on it is on the conservative side because that can range anywhere from two to one generally up to a ten to one right so two to one is conservative of actual new space so let's say I have a terabyte worth of used space for my virtual machines right after compression after deduplication I can expect to see a reduction of the 2% right so what I actually have resided on dis for my fool is going to be roughly 500 gigs right so okay at 500 gigabytes apiece now the incrementals that I'm going to have for two weeks I can potentially have most that six incrementals per week right and I can potentially have three weeks worth so that could be 18 incrementals so how do I determine the size of the incrementals we generally use five to ten percent for change rate of course if you're heavy on sequel or exchange usage those particular virtual machines are going to have a higher daily change rate but we like to use 10% just as a guesstimate right so at 10% for a terabytes worth of data I'm going to have 100 gigs worth of change data per day reduce it by 50% because of our compression and deduplication that works out to be 5 gigs of change data per day right so now you just do a little bit of math here 3 times 500 plus 18 times 5 and that will give you an idea of how much storage space you're going to need for that particular job to meet this retention policy right reversed incrementals a lot more straightforward ok so let's assume these same sizes for reversed incremental let's say remember I only have one full so that fool is only ever going to need 500 gigs right but I will have more incrementals or roll back points same daily change rate so I will have now 20 incrementals at 5 gigs apiece right so if you do the math of course the forward incrementals going to require a lot more storage space than the reversed incremental is but remember it does cost more IO per day other than that that's essentially all I wanted to go over on the whiteboard just to give you an idea of how to deploy beam within your infrastructure Jason is actually going to show you how to configure a proxy on the on the computer self excellent stuff Shawn so appreciate that hopefully that makes it pretty clear for a lot of you that had some of the questions that Shawn was able to answer with the demonstration that he gave for us so now what we're going to do is as Jay Shawn mentioned we're going to go ahead and take it over to Jason Jason is going to do a demo live from the computer itself and you should be able to see it on screen we do recommend that you enlarge your screen if you're watching it right now in the small screen it's going to be kind of hard to read so go to a full size that's probably a good best practice to use to be able to read what's on the screen so all right so we'll go over to Jason thanks Shawn for that very thorough demonstration of the Veen backup architecture so kind of getting into V backup application again this is version 6.5 we're going to focus primarily on the backup infrastructure tab of beam backup hearing what we do is go and add a Windows proxy so to start with what we need to do is add a server that we would like to to be able to use as a proxy for Veeam praveen so to do that let's begin with adding a server which I'll do up top or I can also right click and add a server ok so I actually have a machine in here that I would like to use and keep in mind all the specifications that Shawn mentioned as far as requirements for the proxy and recommendations and I'm using actually a Windows virtual machine in my case here so give it credentials whoops alright so it's going to go into Tecna see if there's any previously installed components you know in my case I believe there is because it's a lab environment components that can be used actually nope the transport is not there doesn't go ahead and add it these are other services that Veen will need to use to be able to do as Sean said retrieve the data from the infrastructure ultimately dupe it and compress it and write it off to your repository so it's like that's just a moment it's determining all the disks to this procs you can read and there we go so now we've added this now we need to go make it into an actual Veen backup proxy which can be done simply by going to the backup proxies up shake up here right click on it and you're add a VMware backup proxy ok and now that VM that I just created the machine that I just added is going to be available in this pulldown and you'll see that some automatic selections here so the first one is going to be how can this proxy access data and in sha went to we have directs an access for being able to retrieve the data directly through the sand fabric the sand network the virtual appliance mode is Veen being a VM or network mode going actually across your local area network will let vm choose automatically vm is going to pick the best one for your infrastructure based on again the the location of it of itself being the proxy it's current load etc that's going to be beaming and we'll make those decisions now but this john said for every 2v cpu or every 2 cores you give the proxy you're going to essentially get a concurrent task or a concurrent job so in my case i have 4 4 v cpu on this proxy so I can have two concurrent tasks now I can increase this number you'll see that turns into a warning icon telling me that only have four cores detected a six core configuration is recommended for running three parallel concurrent tasks so we're gonna leave it as it is I don't want to overwhelm or overload this proxy so we'll leave that there and go to the next step so one of the things you can establish and Veen backup your application is traffic throttling based on specific rules and these rules are actually set globally and automat we identified our leverage based on the location or the network that the proxy is on so you can manage again these rules you know globally here for veem you can add them based on the source and target IP range and kind of you know how much traffic you want to be throttled to and when you want it to occur for my case I'll leave this open for now just kind of knowing that it's there and go ahead and complete creating my backup proxy okay so the backup proxy is now created when you go into a backup job actually go to another feedback up server here and look at a job that I have you're going to see where this is leveraged right on the storage page of a backup job and as I mentioned their automatic selection based on the the proxies current usage its relationship to the storage etc so or you can of course identify them yourself so that being said I'm actually handed the computer over to Sean he's going to show us how to create a backup repository inside of being backup and replication alright thank you Jason so now that we have a proxy right we got to take a look at the next component which is a repository now veem does install all three components by default right so you notice that we had a default backup proxy we do also have a default backup repository which the default here you'll notice is just the local drive on this particular machine ok that's generally probably not where you want to keep it right you want to send it to a specific repository whether that be some direct attached storage or so safe share or just a different media server altogether alright so if I right-click on the repository here and add a backup repository you can simply come in here and give the repository a name we'll call it wbf for right board Friday and you'll notice the different options I have for a backup repository you can select a Windows Server which is just a media server maybe I have what direct attached storage to it a Linux machine right dumb if you want to use NFS or just a manifest storage mounted to that particular Linux machine or you can use a sip share just a regular shared folder there so any of these options are available to you so let's select Windows Server here for example and and you'll notice I can drop down and I can select that same proxy that Jason just created to use as a repository right if I click populate here to populate the different disks on that particular proxy you can use so very easy here the nice thing about having a proxy and repository in one write is remember how the data flow goes once the proxy retrieves the data right and generally if you deploy it via a virtual machine or a physical machine with directs and connectivity that retrieval method is land free right so if I have a proxy and repository combination where the disks actually reside on the proxy itself that performance there's going to be really nice right because the proxy doesn't have to send the data anywhere the storage is already on the proxy itself okay so you do have that option so now just select this local storage on this particular proxy to use as a repository you'll notice you can limit the maximum number of concurrent jobs to this repository right so if I know that I'm going to have four jobs flowing into this particular repository and remember our i/o write the i/o operation is what's important here so let's say for jobs is all I can handle right so I can limit how many jobs can go into this particular repository you can also limit the combined ingestion rate of all the jobs as well that way you don't overwhelm the repository okay will enable it to be a v-power NFS server because it is a Windows machine right so you'll see that it has empanada successfully so now they'll be available via this this menu here and that's pretty much it for creating a repository we can go back to Jason he's going to talk about how would you deploy beams distributed architecture in a remote repository scenario or a robo scenario right remote office branch office excellent Sean thanks for that so we're going to take it back to the white board and have Jason just shows a little bit of what's John's talking about there great all right thanks a lot Sean think so I was a so when we talk about distributed architecture we talked about different modes we talked about the proxies and hot stuff flows together common scenarios we could ask is okay well I would like to get my backups offsite I have a central location or location I like to eat my backups - how does that work for veeam another common another question we have is for remote offices perhaps you have a remote office that you'd like to be able to backup machines with that are running there but you like to be able do that centrally so the beams distributor architecture gives you that capability so the first scenario I drew up here is essentially two sites we have in Atlanta primary site and we have one in Columbus Ohio that's going to be a secondary site in the first scenario I'm going to draw is we're assuming that I'm my production machines are running in Atlanta now I want to back those up to Columbus or at least want to get the backups there the first thing I want to make a point make a point of a mentioning here and thing to remember is while I'm going to show you is getting the backups off-site we always recommend you have a localized copy at your production side as well for a lot of themes features that are required rapid access or quick access to back up so like powering on a backup for instant VM recovery or assure backup lab grabbing a file do anything like that across a wide air connection naturally is not going to be the quickest way to achieve that right so that being said they can see the components I drew up here I have an infrastructure some hosts like Shaun Drew there in Atlanta and I have my backup server and I have my proxy so the proxy again is the the engine or the arms of the is pulling the data from the production storage are pulling my VMs and ultimately they do ping compressing and then backing them up to a repository okay so remember this repository can be windows it could be a sieve share it could be a Linux server with mounted local storage or NFS NFS share and itself a couple of best practices to keep in mind here if I let it back up to a a say remote network share for an example like a sip share keeping in mind what Sean said as far as the i/o they're having to read and write data for synthetic fools and reversed incrementals so by having a Windows repository in this case what I'm going to be able to do is Windows is actually at Windows Server we want you to play our own agent on there we're going for an agent inside there that's going to allow us the offloaded to offload that rebuilding of synthetic fools reversed incremental of fools that can be done on the side to take the i/o off of the win so now are you having to worry about whatever storage is attached to it here this actually your backup storage not having to worry about that you're able to you know take that off the like I said and take off the way and have it all localized now in the case of a network share keeping of my own network share can be accessed directly through here just using a UNC path we're going to recommend again that you access that through a Windows server for that exact same purpose so a Windows Server local disk a Windows server with direct-attached disk or using a Windows server as a proxying server to get to a sub share or or Linux in the case of NFS so just keeping that in mind but remember what I set the beginning we still want to have a localized backup for getting the backups back quickly and this is more of an archiving option for you know when that retention is already expired here we need something more long-term and of course we well we have covered in a previous session we do have V backup cloud edition to get those backups archived into the cloud as another option which we won't touch on today but it is something else that naturally you can do if you're concerned about archiving okay so the other scenario I said was where we do have an infrastructure here as well so let me go and draw that real quick so let's say that production machines running here as well that we need to be able to back up so as we mentioned earlier we're veem has a centralized backup server perhaps I want to be able to manage all that centrally but I want to be able to again it's all about we don't have everything across the way and so I can put a proxy here also so I have a VM proxy again managed centrally and having the proxy server that's going to be able to read from this pre from the VMS over here through the proxy and backing them up locally so again all the management still does essentially or another location but now what we're doing is we're keeping all the data moving and in fact this proxy is also going to be what does our restores as well so it's going to be what's handling the ability to do our virtual machine restores our Lowry stores etc so that's really how the distributor architecture works into remote office branch office and off-site backups so that's how I can come into play for you I will take a look at this and the next episode will how this plays in to replication because replication is kind of the same scenario we're not talking about backups we are still going to have the same architecture coming into play for data moving offloading some that data traffic that we have on our our our way in connection so that being said I'm going to take it back to Jose and he's going to take a smear so EXO Jason thanks for that we're actually going to go to Shawn real quick and he's going to show us on the PC what he some others go ahead Shawn yeah so just a couple of final points here on the actual computer itself I just want to show you where the actual proxy yeah the different repositories come into play when you're creating a backup job right so now that you have a bunch of different proxies you can leave it for automatic selection where Ravine remember we talked about that algorithm that selects the proxy based on not only its availability but how efficient it can process that particular virtual machine but in certain scenarios like what Jason just described up there with the remote offices and whatnot you can come in here and set affinities right so you can set a group of proxies that veem would use for this particular job a group or just a single proxy that bemoan used for the particular job okay just wanted to point that out here you can also select your different repositories tory's just be a drop-down menu I can select the one that I just created so very straightforward very easy to go in there and choose your different prophecies or different repositories it's less it generally isn't needed on the proxy side because that algorithm is very advanced and will select the proper proxy for you okay so that's essentially just tying the different components together that's pretty much all I needed here excellent Sean thanks for that so what we're going to do now is just do some Q&A and that'll be the second part of this episode where we'll go through and take some other questions answer some of the questions that you may have come up with as we go through the show as always remember this is episode two of a five part series so if you didn't get your questions answered don't worry about it we'll continue on we've got three more episodes to go after this so tune in go to VM comm slash whiteboard make sure you register on there you'll get notifications to all upcoming episodes from there so listener you have a question Jason Young let Jason get started here yeah let's see here so what are the three types of backup repositories that you can have that's a good question so there's three that we mentioned lets those up for us and those will go through the chat window so i'm a scaling monitoring them so first one to respond with the correct answer wins so I'll repeat the question again so the three backup repository types that you can have right remember the screen we went through the wizard there were three different options for a backup repository looks like a Morgan said Windows Linux and sifts excellent job Morgan all right very good so Morgan is the winner of that one Sean I'll let you have a question now okay great question so for the vigne proxies how many cores are required per job I repeat the question for the Veen proxy how many cores are required per job okay guys we got a lot of answers coming in on this one let me scroll back to the top very first one gets it let's see like I said in the beginning I apologize if you have a laggy connection that can sometimes make make the difference between first and second this is awesome I love this interaction the scroll wheel will not move fast enough looks like everyone is singing too I think my question was too easy yeah you know makes it harder having a more difficult time alright I'll work on that it looks like hex cipher um said - that is correct you're good two cores per job a little more difficult with this this question here he always asked more difficult questions well so the vean backup server needs there's a minimum amount of RAM and CPU that it needs generally speaking but there's also an additional amount of RAM per concurrent job that you want to run in Veeam what is that amount of RAM that we recommend that you have available for each concurrent job that you want to run and again the proxies are talked about the Veen backup server itself which coordinates those proxies and keeps them talking and all that so what what is that man of ram run I mentioned early on talked about this in the beginning of the episode remember when the backup server itself pulls the VM list right there's a VM list per job so how much ram do we recommend that you have per job for that particular vm list there's also a lot of good answers coming in here but I believe ta hood said to the first is that correct no it's actually not so the great great try because you're on the line of the actual minimum requirements so demo requirements as we said earlier four gigs of ram 4 core 4b cpu but in addition to just running the the typically that's including sequel running locally but you talk about just coordinating the jobs grabbing the VM list as Shawn said there is a set amount of RAM that we recommend having addition to those memory requirements to coordinate all that talking there so it looks like our piece at 512 Meg perfect that is the answer that the answer so very good all right so we have three questions today so we said all right three questions three prizes for those of you that that did win Matt will you pull it put up a Jose's email address please send a Jose an email address with your name your shipping address and you know what what question you answered correctly and we'll go ahead and get those out to you next week all right well very good so it don't work then keep in mind you this is Sean mention image and you're like a five five part series so we're gonna get more into restores replication you know moving forward and it will be a grand prize I said it's it's a very very cool you know Veen backpack my laptop bag backpack that you'll go to get there so and so they always says you know I'm going to fill in a little bit here you know go to Veeam comm you know for more information of course to download trials of all DVM solutions and of course go to the vm user forums to even get more information there's a lot of varriya we have developers out there the solution architects they're very knowledgeable to answer any other questions you have and of course if not just come to us you know we you can get through us through our emails are up there but i think go through jose go get to us now but it's um you can just do Jason dot Leyva so le IV a of them calm or Shawn Lou sha W n dot li e you at VidCon we're happy to answer anything you have right okay absolutely and and and I know we kind of went through the two different backup modes rather quickly during today's episode so if you have any further questions regarding yet you can feel free to email us or if you have our user's guide there is a section in there that details to two different backup modes and you know there's nice pictures drawings and diagrams to help illustrate what I was trying to illustrate on the whiteboard okay and sometimes it even helps to have someone like ourselves actually look at your infrastructure we're happy to reverse web X's or just talk about it and draw out what works best for you so we can certainly do that okay right on that note sorry for the technical difficult to date difficulties today but thank you for being patient and joining us for today's call remember there's three more upcoming episodes where we're going to cover replication we're going to cover you where technology sure backup the on-demand sandbox in episode 4 and then episode 5 we're going to talk about your different recovery options some of the questions that one of the questions that I remember being asked today with the application where image processing right backup of specific applications block-level restores or item-level restores for those specific applications that will be episode 5 so our next episode coming up next week right we're going to do them in succession here every week we're gonna have an episode so episode 3 is actually going to be covering our replication architecture tune in for that one there is a lot to cover there there's a lot of considerations lots of best practices there to tuto be aware of so join us next week hope everyone has a great weekend thank you for joining us thanks everybody

Channel: Veeam

Views: 7,638

Keywords: veeam, backup, replication, virtualization, vmware, file restore, hyper-v, windows, linux, vm, vbms

Id: QvTqWP9UlpQ

Length: 49min 34sec (2974 seconds)

Published: Fri Sep 11 2015