Offsite Backup Solution Needed
-
@DustinB3403 said:
Well he'd be making the full onsite, and seeding to the other (left that part out) with both NAS on premise.
Removing the internet from the picture.
But a NAS to NAS replication is still going to transfer a crapton of data when you do a local full backup the first time after everything is seeded and the NAS moved back offsite.
Replication at the hypervisor level or the VM backup level is needed to provide enough intelligence to transfer replication offsite.
-
Does Veeam Replication create a snapshot though?
Doing local or not isnt really an issue, swimming in spare hard drive space
-
@JaredBusch said:
@DustinB3403 said:
Well he'd be making the full onsite, and seeding to the other (left that part out) with both NAS on premise.
Removing the internet from the picture.
But a NAS to NAS replication is still going to transfer a crapton of data when you do a local full backup the first time after everything is seeded and the NAS moved back offsite.
Replication at the hypervisor level or the VM backup level is needed to provide enough intelligence to transfer replication offsite.
Why would additional data get sync'd over after the initial seeding? (I'm honestly curious)
-
@Sparkum said:
Does Veeam Replication create a snapshot though?
Doing local or not isnt really an issue, swimming in spare hard drive space
replication works through the backup copy.. it doesn't effect the host at all. i.e. no snapshot on the VM host.
-
@JaredBusch said:
@DustinB3403 said:
Well he'd be making the full onsite, and seeding to the other (left that part out) with both NAS on premise.
Removing the internet from the picture.
But a NAS to NAS replication is still going to transfer a crapton of data when you do a local full backup the first time after everything is seeded and the NAS moved back offsite.
Replication at the hypervisor level or the VM backup level is needed to provide enough intelligence to transfer replication offsite.
WHAT? why would you say that? and now you're talking more about a continuous replication and probably never doing a full reseed.
and besides, can he even do a hypervisor replication without having a hypervisor in each location?
-
@DustinB3403 said:
What are you trying to backup, I'm guessing your VM's.
If so can you back them up to a local storage unit like a Synology NAS, and use that as the push device for your off-site?
Definitely the way to go here. Trying to push backup over 5/5 (depending on amount of data) is gonna be....well tough.
By no means was it in one shot.
I was going server by server, 2 worked successfully, the third the **snapshot outgrew the server **and crashed it.
To be honest, this is not a Veeam issue, it's a storage problem. You'd have the same problem with other software applications that backup at the VM level.
Replication would be a good idea as mentioned above. However, it doesn't solve your off-site backup issue. It gives you a near-term DR solution. The good thing about replication is that you can multiple restore points and you don't need to run another full once you seed the DR location. You still need an off-site backup solution and even going Forward Incremental, you still need the occasional full which, mentioned above, will kill your Internet. Even looking at doing someone at the NAS level like rsync, you'll likely run into the same situation when the full gets kicked off occasionally.
Other solution for offs-site would be with tape and Veeam backup copy jobs. Not ideal since you'll need it at multiple locations. You might try using hard drives instead and that can be done with Veeam, but depending on your data retention needs, who knows how many you'd need.
-
Veeam has a system where they suggest new full backups on a regular basis - wither that's actually needed or not, I don't know.
I use Dell's Appassure - it's a continuous backup - a full is only done one time, unless the backup location become corrupt for some reason (rare). After the single full, only changes are backed up based on the changes.
-
@Dashrender said:
@JaredBusch said:
@DustinB3403 said:
Well he'd be making the full onsite, and seeding to the other (left that part out) with both NAS on premise.
Removing the internet from the picture.
But a NAS to NAS replication is still going to transfer a crapton of data when you do a local full backup the first time after everything is seeded and the NAS moved back offsite.
Replication at the hypervisor level or the VM backup level is needed to provide enough intelligence to transfer replication offsite.
WHAT? why would you say that? and now you're talking more about a continuous replication and probably never doing a full reseed.
and besides, can he even do a hypervisor replication without having a hypervisor in each location?
There will be a server running VMWare at the offsite as well
-
In a similar situation with limited bandwidth like that we just used Symantec to dump to tape. Nice people in a van came by each week to get the tapes.
-
In reading DenisKelley's post and then re-reading JB's post - I suppose you could go for incremental replication at the hypervisor level, but I don't know if that requires a server with a hypervisor on it at the remote location. Be that as it may, it's not a backup, it's a replication of the live system. So you can't go back in time. If the live system gets infected, and that infection is replicated to the DR site, you're done. So again, this is not backup.
How much data are we talking about?
You mentioned that your server crashed (I'm assuming your VM host) because it ran out of space due to snapshots?
Wow - what's your change rate? How much total data do you have?
I don't know how much extra storage you have on that server, but if you're running it out of space because a snap file is there, damn. Sounds like you have a huge change rate going on. Depending on your change rate, you might not even be able to replicate your backups over night with a 5/5, mathematically it might not work out.
-
@MattSpeller said:
In a similar situation with limited bandwidth like that we just used Symantec to dump to tape. Nice people in a van came by each week to get the tapes.
Which a great bon-fire is held weekly?
-
Yeah so there are a few different items being discussed.
Continuous replication is not a backup. It's an Oh-Shit recovery tool, where you are making a ready to boot copy of everything on a separate host.
- this does not sound like what you want
Backups include
- Full Backups - backing up everything VM related
- Incrementals or Delta's - Only the changes since the last backup.
Incrementals are what you appear to want, but then you mention that you'll have a Hypervisor at the remote location.
So are you doing / hoping for a Continuous Replication and Backup scenario where you use two types of recovery?
-
@MattSpeller said:
Nice people in a van came by each week to get the tapes.
How do you know they were nice? Did you actually speak to them?
-
@BRRABill said:
@MattSpeller said:
Nice people in a van came by each week to get the tapes.
How do you know they were nice? Did you actually speak to them?
Yeah they wouldn't take tape from anyone but IT staff, checked ID every time. Polite and professional.
-
@BRRABill said:
@MattSpeller said:
Nice people in a van came by each week to get the tapes.
How do you know they were nice? Did you actually speak to them?
10 years ago when I was using tape, we had Iron Mountain come by twice a week and swap boxes of tapes in a rotation. That guy was nice. Now I have a better system where I copy backups offsite to Amazon S3 and Glacier.
-
@Dashrender said:
In reading DenisKelley's post and then re-reading JB's post - I suppose you could go for incremental replication at the hypervisor level, but I don't know if that requires a server with a hypervisor on it at the remote location. Be that as it may, it's not a backup, it's a replication of the live system. So you can't go back in time. If the live system gets infected, and that infection is replicated to the DR site, you're done. So again, this is not backup.
How much data are we talking about?
You mentioned that your server crashed (I'm assuming your VM host) because it ran out of space due to snapshots?
Wow - what's your change rate? How much total data do you have?
I don't know how much extra storage you have on that server, but if you're running it out of space because a snap file is there, damn. Sounds like you have a huge change rate going on. Depending on your change rate, you might not even be able to replicate your backups over night with a 5/5, mathematically it might not work out.
A replication of a live system is completely fine, might actually be nice.
We have our onsite backups that go back 4-8weeks so infection isnt really our concern with the offsite, our concern is if we lose the building.
Total data is pretty big. If I was to guess...4TB? plus or minus 1TB (2TB being FileServer)
Change....as well probably pretty big, the biggest part right now (cause of how we do it but it can be changed) is DB dumbs of our SQL, so we would obviously change that, all servers change 100-200GB? maybe more, honestly not sure, DOESNT NEED TO BE EVERYDAY
Talking every week / every month (for less important)
Just plain and simple, whats the least painfull way to get backup if a plane flew into our building.
If our sharepoint site was 3 weeks old, but our POS was 1 days old, we're not doing too bad.
-
Did you ever talk to veeam about why snapshots were crashing your server? Do you have really old/under-powered hardware with super slow hard drives?
-
@wrx7m said:
Did you ever talk to veeam about why snapshots were crashing your server? Do you have really old/under-powered hardware with super slow hard drives?
Havent talked to them no, its was pretty black and white VM crashed due to resources, delete snapshot and poof it works.
(almost) everything is running off of quick systems, quick SAN's mainly all 15k or SSD
-
@Sparkum 100-200GB per day in changes?
That's a very large Delta if you're trying to replicate those changes off site.
-
@Sparkum I have been using Veeam since version 6.5 and now on version 9. I absolutely love it. I would still take a look at the reason you ran out of resources. It seems really odd that that you would have that problem on newer hardware.
I also have a large file server. About 2 TB is used and with version 9 and vSphere 6, the full backup only takes about 16.25 hours. On version 8 it took twice that long.
