Veeam DOES recommended avoiding low end NAS devices, and recommends SAN over NAS because Veeam wants block protocols. These parts are true and we don't need to watch videos as they are available in writing from @Rick-Vanover - we even have the author of the best practices here in the community!
The keys here are "low end" which is an issue around support. The misleading bit is that NAS means server, so low end servers are every bit affected in the same ways. The QNAP, Synology, ReadyNAS and other such devices are not actually NAS but Unified Storage, SAN as much as NAS. That Veeam recommends SAN instead of NAS is a protocol choice, it does not make those devices any less applicable. We should not be calling them NAS, as that is misleading, they are equally both.
If we really look at the guidance and consider what it could mean, the only real concern is "low end" and low end is always of some concern. Why spend so much on Veeam and Windows licensing and then get cheap on the hardware? You want solid storage hardware and solid support. But nothing here is telling us that there is anything wrong at all with these kinds of devices and certainly the issue is not some kind of corruption caused by the fact that they are in this product category.
It's true that you can make stateless systems without DevOps tooling and approaches. But the nature and assumptions of those systems is that you cannot. Just letting arbitrary logins (even of administrators) can undermine that. One of the beauties of the pure DevOps model is the lack of logins. Much like functional programming.
How about setup MySQL replication to remote site and then enable MySQLdump local backup on the DR site as well with increased frequency than daily ( may be twice a day). This way we have an up to date/latest copy and in case let's say there was a drop table command on master, and primary site failed, I can still switch to secondary, use the latest mysql backup to restore and make it up and running.
Yup, that's what I would do. Get HA and DR all in one setup. Have it take backups 24 times a day if you want. The impact is pretty much zero.
So I've waited about 30 minutes or so, much longer after the backup completed. I still have a snapshot called XO_DELTA_BASE_VDI_SNAPSHOT. Am I able to delete it and it not affect the backup or is the delta based off of the snapshot?
Did you every get clarification on this? I suspect this is needed for the delta backup.
Yes, it uses the snapshots to make the backups. That's what I figured it was doing, but since Dustin didn't see it I thought maybe something was wrong.
We resolved it in another thread, I can't remember which one at this point.
The one big difference is that snowflake firms (or any size) tend to lean towards platform-based, agentless backups while DevOps firms almost never take platform-based backups because they have no need to ever restore a full VM, only the data.
It's the curse of large companies. Once you get to a certain size you have more than enough unhappy customers (or people with a reason to make you look bad) that will be vocal in any setting that you just always have them no matter what you do. No way to be a huge company without that happening.
Looks like your connection to MangoLassi was lost, please wait while we try to reconnect.