@DustinB3403 said in Nextcloud Backup System Idea: Practicing process also requires that you practice developing process and having holes punched into said idea. Yep. And you've validated some holes I've considered, but didn't explicitly write in my posts.

It's been a while, so I missed some. Here's a much better break-down: https://www.petri.com/new-file-types-windows-server-2016-hyper-v-vms

What account the sql account or the azure login?!

@travisdh1 said in Backup Systems without on-site external storage: @scottalanmiller said in Backup Systems without on-site external storage: @black3dynamite said in Backup Systems without on-site external storage: @scottalanmiller said in Backup Systems without on-site external storage: @black3dynamite said in Backup Systems without on-site external storage: @obsolesce said in Backup Systems without on-site external storage: I've recently come across Restic and looks great: Site: https://github.com/restic/restic Documentation: https://restic.readthedocs.io/en/latest/ I haven't tried it yet, but it's on my list to try on my KVM server using Google's cloud as a test. I’ve only tested it with backing up nextcloud user data and it’s been working great so far. What are you backing up to? I only tried an external hard drive and sftp to a Linux Server. I would like to try Backblaze. I would like to check out Wasabi. At first glance, https://wasabi.com/pricing/ looks like it could be a little cheaper than B2. Would definitely be cheaper if you need to download significant amounts often. That was its selling point - a bit cheaper than even B2, but with full S3 compatibility.

@eddiejennings said in Food for Thought: Backups - from terrible to functional: @jaredbusch Wow. Was an initial seed of a server. So totally expected when the WAN pipe is only 10mbps up. 120GB of real data on a thin provisioned 500GB vhdx.

@dims said in Is the 3-2-1 rule antiquated?: the majority of the previous cases of implementing such solutions indicates that the most popular would be the one where the data would first be replicated between 2 hosts, on site and one off prem. Yes, because normally that is insant, you'd not want to wait for the WAN copy before making the local one.

@nashbrydges said in Backing up user data on remote computers: @scottalanmiller said in Backing up user data on remote computers: @eddiejennings said in Backing up user data on remote computers: @scottalanmiller said in Backing up user data on remote computers: @eddiejennings said in Backing up user data on remote computers: @scottalanmiller said in Backing up user data on remote computers: @eddiejennings said in Backing up user data on remote computers: @scottalanmiller said in Backing up user data on remote computers: @eddiejennings said in Backing up user data on remote computers: @scottalanmiller said in Backing up user data on remote computers: We use NextCloud, then only back that up, not the remote user devices. Are you running your instance of NextCloud in a VPS with extra block storage for your files, or using their enterprise plan? We run out own. Forgive me for seeming thick, but you mean on your own hardware in your office or at a data center? We never run on premises for production. I figured not; thus, they're at a colo. No, we use cloud computing. Somehow I'm confused, so you are running your NextCloud in a cloud server instance like Vultr? Of course. I'm assuming you're using the native sync clients? Are you using both Windows and Linux clients or just Linux? I've tried the Windows one on a couple laptops and found that the synching was really clunky and not working well. Have you run into any issues? Both. All Linux internal, it's rock solid. Some Windows for external users, and they do have some issues. But... that's expected, it's Windows.

@scottalanmiller said in SQL Server Backup Design: @jaredbusch said in SQL Server Backup Design: @tim_g said in SQL Server Backup Design: I'm with Jared on this one... Backing up through the application layer (SQL) as often as you can depending on change frequency. For example, every 15 minutes. Hourly and daily through the SQL backup tools. At least daily full VM backup at the hypervisor level. I prefer backups that use a standard file format, so you don't have to rely on Veeam for example to restore it. Veeam has screwed up too many times for me to want to rely on it like that. I have never had been fail Except for statements like this. For some reason Siri does not like Veeam yet. Even though correct it a lot

I've used the built in backup. It works great, preserving everything properly, as far as I can tell.

Odds are you can create a new VM, and simply attach the disks to the VM (in the correct order) and be back up and running.

@coliver I know, I wasn't even included in the conversation at the time when we migrated to O365, and I wasn't included in the conversation when they setup Hyper-V. Nor was I included when they built this VM, or the other reporting VM on Hyper-V to which 16GB of memory and 2 cores assigned to it... #SweepItLikeAJanitor

@Ambarishrh said in LAMP replication to DR site: 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.

@JaredBusch said: @Dashrender said: @DenisKelley said: @Dashrender said: @DenisKelley said: @Dashrender said: @JaredBusch said: @wrx7m said: @Dashrender said: @JaredBusch said: @Dashrender said: You create a local backup with Veeam - which of course creates a snap.... and then you do a replication with Veeam from one hypervisor to another? why are you using Veeam to do that instead of the built in hypervisor tools? But that's really beside the point. Because VMWare. Doing that clearly makes the server run a snap twice (unless it can be run in a single job). and put strain on the VM host while replicating to the remote site. Backups run nightly. Not all servers are replicated Replication gives you more restore points throughout the day in addition to the failover capability How do you get number 3? It creates replication points? That's not how I've ever understood how replication works. Veeam 9 offers multiple restore points on replicas - https://www.veeam.com/vm-advanced-replication.html under failover and failback section. Even Hyper-V has this built into replication. You can choose to keep XX number of replication points. Honestly this is not much different than people keeping XX snapshots on the local host for immediate rollback needs. you can't pick and choose roll backs, if you pick two snaps ago, you loose the one from one snap ago. See above about replication I just posted. I'm using replication like JB in that I'm just using it for convenient backup not true replication for DR failover. JB may be doing it similarly. Does that use 12x time disk space of the VM? Not at all. It similar to Forward incremental. One big file with delta snaps. Cool feature in Veeam. Built into every replication system I am aware of. Pretty much. It's very standard.

So I've got my SR reattached, just need to figure out how to import the VM's from the SR.