KVM Backing and Support
-
@scottalanmiller said in KVM Backing and Support:
Use agent based,
Screw that shit. Let's just jump back to 1999 shall we?
@scottalanmiller said in KVM Backing and Support:
modern DevOps backups
This is not even a thing. DevOps is not backups. If you are trying to talk about stateless, that does not apply to the SMB almost 100%, and still doens't account for backing up the data bits.
-
@jaredbusch said in KVM Backing and Support:
This is not even a thing. DevOps is not backups. If you are trying to talk about stateless, that does not apply to the SMB almost 100%, and still doens't account for backing up the data bits.
"We use <Insert cloud buzzword> so we don't need Backups" has been the rallying cry of developers who think they understand infrastructure for the past 10 years. Fun thing I learned over lunch with a CIO last week, business continuity insurance will reject your claim if this was the reason (Too many people have thought using AWS alone was a backup).
There are other reasons for doing Hypervisor based backups API's for backup and replication beyond being able to restore a few files.
-
CBT. Having an API that does differential block WITHOUT having to read the data. Not all OS's Applications have a clean way to do this. Doing block based agent backups with 20TB of data means I have to read 20TB of data to find the 500MB that changed. Long backup windows, and if you use a log structured back end for your primary storage a brutal random IO storm.
-
Test/Dev workflows that use the backup for copying out clones for test/dev (See what Cohesity, Rubrick, and Veeam Labs enable).
-
Write spilter API's. VAIO lets you get to a block based few second RPO without using a kernel module that can bring down the host if it fails.
-
Data analytics off secondary copy. Commvault can do this, and I expect to see more data mining done against secondary storage copies.
-
Function as a part of a larger orchestration suite for testing DR (SRM as an example).
-
-
@obsolesce said in KVM Backing and Support:
But it's so convenient and easy to be able to back up (agentless) VMs at the hypervisor level with the ability to restore files within VMs like you can with Hyper-V backup solutions.
- Is it? How is "so convenient" really important in IT? Unless you can put a dollar value on that convenience, it's not relevant.
- It comes at a cost, a cost of reliability and performance. I see loads of shops getting useless backups because they thought convenience trumped "working". It encourages lazy, bad backups and processes.
- Once you do all the due diligence and effort to get good backups the difference in effort between agentless and agent is generally nominal.
-
@jaredbusch said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
Use agent based,
Screw that shit. Let's just jump back to 1999 shall we?
@scottalanmiller said in KVM Backing and Support:
modern DevOps backups
This is not even a thing. DevOps is not backups. If you are trying to talk about stateless, that does not apply to the SMB almost 100%, and still doens't account for backing up the data bits.
DevOps is not backups, but good DevOps changes how backups need to be used. Backups are no longer necessary to make up for system administration deficiencies. Backups in the non-DevOps world are often used as a crutch, an expensive one.
-
@jaredbusch said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
Use agent based,
Screw that shit. Let's just jump back to 1999 shall we?
It's not a jump back, it's sticking with the more enterprise solution. Agentless is limited in scope and requires support at the hypervisor, OS, and application level. Essentially no enterprise shop can use it, as there is no agentless system that supports the range of apps that shops use. So no enterprise has moved to agentless. Many use it as an "extra" piece, making backups more complex and more expensive, rather than less.
Really, for the time being, agentless is mostly just marketing hype. So jumping to "tried and true" rather than "sounds impressive and is rarely thought through" is exactly what we should want.
-
@storageninja said in KVM Backing and Support:
"We use <Insert cloud buzzword> so we don't need Backups" has been the rallying cry of developers who think they understand infrastructure for the past 10 years.
Actually, no one says that. No one.
The point is smaller, faster, more focused backups of relevant data. Not loads of fluff to sell more hardware.
-
@scottalanmiller said in KVM Backing and Support:
Actually, no one says that. No one.
The point is smaller, faster, more focused backups of relevant data. Not loads of fluff to sell more hardware.I've had this conversation with a shocking amount of developers who thought Cloud=automated unlimited backup and DR.
It often flows from "Everything's in git hub!" (follow by littering of state all over the place, or ignoring that just because the database was delivered by PaaS, or deployed from a template doesn't mean you don't need to do SOMETHING to protect the data.
-
@storageninja said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
Actually, no one says that. No one.
The point is smaller, faster, more focused backups of relevant data. Not loads of fluff to sell more hardware.I've had this conversation with a shocking amount of developers who thought Cloud=automated unlimited backup and DR.
Well, DevOps is never developers. Any developer using that term is confused and that could apply to any lay person. Talking to any end user about backups makes no sense, that's no in their scope. In IT, DevOps always has backups.
-
@scottalanmiller said in KVM Backing and Support:
there is no agentless system that supports the range of apps that shops use
Veeam can hit Exchange/SQL/AD/Oracle/Windows/Linux (OS and file). For a lot of SMB's that's their estate.
-
@storageninja said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
there is no agentless system that supports the range of apps that shops use
Veeam can hit Exchange/SQL/AD/Oracle/Windows/Linux (OS and file). For a lot of SMB's that's their estate.
Not as many as you'd think. I know almost zero. Someone will find an example case, but they will be so small that it's just silly to mention. In the real world, even tiny SMBs deal with things like QuickBooks, Sage, SAP, MySQL, etc. that aren't covered by Veeam.
-
@scottalanmiller said in KVM Backing and Support:
@storageninja said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
Actually, no one says that. No one.
The point is smaller, faster, more focused backups of relevant data. Not loads of fluff to sell more hardware.I've had this conversation with a shocking amount of developers who thought Cloud=automated unlimited backup and DR.
Well, DevOps is never developers. Any developer using that term is confused and that could apply to any lay person. Talking to any end user about backups makes no sense, that's no in their scope. In IT, DevOps always has backups.
These tend to be in shops or departments where you have "Developers gone wild" where they don't have IT functionally. Just a credit card and a public cloud
-
@storageninja said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
@storageninja said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
Actually, no one says that. No one.
The point is smaller, faster, more focused backups of relevant data. Not loads of fluff to sell more hardware.I've had this conversation with a shocking amount of developers who thought Cloud=automated unlimited backup and DR.
Well, DevOps is never developers. Any developer using that term is confused and that could apply to any lay person. Talking to any end user about backups makes no sense, that's no in their scope. In IT, DevOps always has backups.
These tend to be in shops or departments where you have "Developers gone wild" where they don't have IT functionally. Just a credit card and a public cloud
Well, that's fine, but a shop without IT isn't one you really talk to about backups. That's like saying "I asked my grandparents and they didn't feel that they needed backups." No one is doubting that non-technical or end users don't understand data protection. But that's not related to IT issues of believing backups aren't needed.
Any shop that thinks that they don't need IT is going to have a lot of crazy notions. They probably don't believe in passwords, either.
-
@scottalanmiller said in KVM Backing and Support:
QuickBooks, Sage, SAP, MySQL
Quickbooks hosted game has gotten a lot better (My last employeer had migrated to it).
Sage uses Microsoft SQL for some of their apps, or they have apps that dump a local copy on a schedule so a block consistent backup of the file is good enough. MySQL (or Maria) I used to see more of as part of LAMP stacks, but honestly where I saw it used in SMB's no one was managing the MySQL in any meaningful way and it was generally crash consistent (or it had a rotation of a local dump that was captured in a crash consistent copy of the VM). Veeam can run scripts to a VM before and after backups if you want to put a database in hot standby mode (What we did for some more weird databases) so when you recover the VM you know the database will be consistent. Worst case you can do a stop service before backup and resume afterwards script.SAP I generally see hosted for SMB, although more SAP runs on Microsoft SQL than Oracle (of which Veeam can backup both). HANA is a different beast but if your running HANA in a SMB you are an outlier (HANA is only certified on appliances, so I suspect most SMB's consuming it would do so as a service from somewhere else).
-
@scottalanmiller said in KVM Backing and Support:
Any shop that thinks that they don't need IT is going to have a lot of crazy notions. They probably don't believe in passwords, either.
Nah, you just use API keys that hopefully bill didn't check into Github and rack up a 50K bill in an hour.
-
@storageninja said in KVM Backing and Support:
SAP I generally see hosted for SMB, although more SAP runs on Microsoft SQL than Oracle (of which Veeam can backup both). HANA is a different beast but if your running HANA in a SMB you are an outlier (HANA is only certified on appliances, so I suspect most SMB's consuming it would do so as a service from somewhere else).
A lot of small SMB still operate in places without reliable internet, so lots of it is not hosted.
SAP primarily runs on HANA, not SQL Server or Oracle, those are legacy deployments that haven't updated yet. SAP makes their own database, and it only runs on Linux. HANA isn't appliance only, in our latest SAP talk (two weeks ago) SAP didn't even offer appliances, local install to Linux servers only.
HANA is more affordable for SAP than any other offering, so a pretty big deal for SMBs. Only larger shops can afford SAP without HANA, and as HANA is the high performance, recommended path, makes the least sense for larger shops to do the less supported and performing offering.
-
@storageninja said in KVM Backing and Support:
). Veeam can run scripts to a VM before and after backups if you want to put a database in hot standby mode (What we did for some more weird databases) so when you recover the VM you know the database will be consistent. Worst case you can do a stop service before backup and resume afterwards script.
Sure, but at some point, we've lost the benefits versus agent based or just scripted and we are only deploying the backup infrastructure in that way to prove a point - which is not ITs job to do.
-
I can't argue the merits of DevOps Backups, but this article seems to agree with @JaredBusch and @StorageNinja that "DevOps backups" are a horrible idea.
-
@scottalanmiller said in KVM Backing and Support:
@storageninja said in KVM Backing and Support:
). Veeam can run scripts to a VM before and after backups if you want to put a database in hot standby mode (What we did for some more weird databases) so when you recover the VM you know the database will be consistent. Worst case you can do a stop service before backup and resume afterwards script.
Sure, but at some point, we've lost the benefits versus agent based or just scripted and we are only deploying the backup infrastructure in that way to prove a point - which is not ITs job to do.
Isn't it exclusively IT"s job to deploy the backup in a way to prove that what is being backed up is consistent and usable?
I mean, to sound like a fool here "we" have audits to meet and certainly one of those annoying questions will be "do you produce consistent backups?"
-
@dustinb3403 said in KVM Backing and Support:
I can't argue the merits of DevOps Backups, but this article seems to agree with @JaredBusch and @StorageNinja that "DevOps backups" are a horrible idea.
That article says nothing of the sort. In fact, it highlights the opposite. It even points out that DevOps approaches will work where traditional backups have less or no chance.
There's no risk to DevOps style backups. If there appears to be, they are misunderstood. They might take more effort and skill, they don't allow for lazy "just click and button and hope for the best" approaches commonly promoted as the purpose for other approaches, but when you do them, nothing is more reliable.
-
@dustinb3403 said in KVM Backing and Support:
@scottalanmiller said in KVM Backing and Support:
@storageninja said in KVM Backing and Support:
). Veeam can run scripts to a VM before and after backups if you want to put a database in hot standby mode (What we did for some more weird databases) so when you recover the VM you know the database will be consistent. Worst case you can do a stop service before backup and resume afterwards script.
Sure, but at some point, we've lost the benefits versus agent based or just scripted and we are only deploying the backup infrastructure in that way to prove a point - which is not ITs job to do.
Isn't it exclusively IT"s job to deploy the backup in a way to prove that what is being backed up is consistent and usable?
Once you are dedicated to doing backups well, why not take the trivial additional effort to do them "really well"? That's kind of the point. Modern DevOps style backups aren't that much harder. Agentless only gets really easy when you use it to avoid really testing.
