I would move PBS to the PVE environment since your just dumping data on the NAS anyways. At least then it’s replicated. Don’t forget to backup your encryption key.

@scottalanmiller
Nice, let us know how it goes.

@JasGot said in MSP Backup Product - Local Storage:

@dbeato said in MSP Backup Product - Local Storage:

@JasGot said in MSP Backup Product - Local Storage:

@CCWTech said in MSP Backup Product - Local Storage:

@JasGot said in MSP Backup Product - Local Storage:

@CCWTech said in MSP Backup Product - Local Storage:

@scottalanmiller I just had a phone conversation with Craig at Backup Assist (they are members of this forum I believe). They are in the process of rolling out a product that may fit our needs. He's going to do some research and schedule a call. I will keep you in the loop.

Just curious, what is unique about your needs that their Multisite Manager didn't address?

I'm not sure. When Craig called me and asked about what I was looking for, he mentioned that they are coming out with a new product in the very near future that may work the best. I haven't explored any further than that at this point.

Based on our conversation here, this may be all you need.
https://www.backupassist.com/multisitemanager.html

BackupAssist however is just a wrapped Management of Windows Server Backup, I used to recommend it but ever since using Veeam I have not moved back. The free version is phenomenal of the Veeam Backup Agent and if you have Exchange or SQL you can still pay for it or use the free up to 10 Community edition.

It's so much more than a wrapper.

Should be its own thread, but do you know of anything similar for Linux?

@IRJ said in Windows Server 2012 R2 - Share Auditing for Changes:

I know you use wazuh..

Check this out

https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html

Thanks! Checking out setting this up. Hopefully, it will reveal the culprit.

@FATeknollogee said in Vultr backups:

This isn't exactly related to OP's post...
It would be nice if there was a "clean & easy" way to "migrate" your vm's from Vultr to say a co-lo.

If you use a DevOps system, then there always is. If you use normal backups like Veeam, it's easy, too. Same with any platform, platforms don't make lock in, that comes from how it is set up. It's as easy to go from Vultr to colo as from anything else to colo.

@Pete-S said in “Catastrophic” hack on email provider destroys almost two decades of data:

So if you make a backup to something like Backblaze. Would that be considered an offline backup?

Depends how it is done. It's online, not offline. But it can be airgapped.

/proc doesn't differ too much with LXC.

[root@acl-jira ~]# ls /proc 1 24924 24951 25368 275 322 bus diskstats interrupts key-users locks net slabinfo thread-self zoneinfo 12471 24925 24952 25369 295 323 cgroups dma iomem kmsg mdstat pagetypeinfo softirqs timer_list 12581 24926 24953 25370 316 54 cmdline driver ioports kpagecgroup meminfo partitions stat tty 24897 24937 24955 25381 318 56 consoles execdomains irq kpagecount misc sched_debug swaps uptime 24908 24938 25157 25382 319 69 cpuinfo fb kallsyms kpageflags modules schedstat sys version 24909 24939 25258 25383 32 acpi crypto filesystems kcore latency_stats mounts scsi sysrq-trigger vmallocinfo 24910 24950 25286 25386 320 buddyinfo devices fs keys loadavg mtrr self sysvipc vmstat [scott@lax-lnx-jump proc]$ ls /proc 1 112 2 24453 24612 31 38 427 532 644 674 759 acpi diskstats ioports kpageflags mtrr softirqs uptime 10 12 20 24455 24613 32 39 428 557 645 676 8 buddyinfo dma irq latency_stats net stat version 100 13 21 24460 24621 326 393 429 598 646 677 9 bus driver kallsyms loadavg pagetypeinfo swaps vmallocinfo 101 13532 21810 24461 2599 33 4 43 599 647 681 9133 cgroups execdomains kcore locks partitions sys vmstat 102 14 22 24510 27 332 403 430 6 648 682 9214 cmdline fb keys mdstat sched_debug sysrq-trigger zoneinfo 103 15 23 24512 28 34 421 431 612 654 683 968 consoles filesystems key-users meminfo schedstat sysvipc 105 16 23974 24520 29 35 424 432 613 659 684 969 cpuinfo fs kmsg misc scsi thread-self 106 17 24 24562 3 36 425 44 615 662 694 98 crypto interrupts kpagecgroup modules self timer_list 11 18 24449 24568 30 37 426 517 643 664 752 99 devices iomem kpagecount mounts slabinfo tty

Container on top. KVM on bottom.

@scottalanmiller said in B2 Backup checkup:

@Emad-R said in B2 Backup checkup:

Then if you do this how you do you check that the Backups are good or you just the tar archive.

You'd untar them.

That is a full check. But without paying to download the file you just uploaded, you hash the file first and send the hash along with the upload. B2 will hash it when completed and verify that it matches your supplied hash. If it doesn’t, it asks it to reupload.

@Emad-R I agree with Emad here, Robocopy is hard to beat for simplicity and reliability.

@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.

@obsolesce said in Agent and Agentless Backups:

@stacksofplates said in Agent and Agentless Backups:

@obsolesce said in Agent and Agentless Backups:

@stacksofplates said in Agent and Agentless Backups:

As much as I like to argue with @scottalanmiller I have to agree that usually agents are easier.

Because the agent based backup meant that to recover the entire guest, I would have to mount a special ISO, it wasn't nearly as straightforward as "restore this backup from 15 minutes ago to Host 2".

That is in no way a requirement of agent based systems. This sounds more like there isn't a reliable way to reproduce a system and the data isn't on a separate volume. Make sure the systems can be rebuilt immediately and you can just reattach the data and be done.

Even with something as simple as ReaR, you define your skeleton volumes you want backed up and include that in your template.

Example (I'll use Ansible since that's what I know):

The template would have this in it:

BACKUP_PROG_INCLUDE=('{{ backup_dirs | join("' '") }}')

You'd have a list (in this case called backup_dirs) that gets iterated over:

backup_dirs: - /home/* - /data/* - /var/www/html/*

That backup_dirs list is specific to each machine when it's created.

The agent based stuff is really simple because it can very easily be specific for each machine and always be specific when the systems are built without any work after the initial set up.

Just because a system is backed up via agentless backup doesn't mean the VMs data can't be separate. I could have a VM backed up agentlessly that has its data on a separate volume / virtual disk... then I could instantly restore the VM and OS, reattach the data, and not have to rebuild shit.

That's not why I said that. If you have to fully restore a system from an ISO the agent built, then it doesn't sound like the data was separate.

No I meant you would boot to a recovery/boot ISO so you can restore the server from within the recovery encironment

You're missing what I'm saying. If the data volume is separate you just attach it to a fresh VM and don't have to do that at all. The only time you need to rebuild from that recovery environment is when either the data isn't separate or you can't reliably reproduce the OS volume.

@obsolesce said in Backup Windows with UrBackup:

I like the way MBS (as how Microsoft defines as "Modern Backup Solutions") work. Most do CBT very well, like Veeam, SC-DPM, and other modern solutions.

I literally refer to these as legacy backups, lol.

Glad to know this worked. I have had 3 different Synology NAS boxes over the past 6 years- An 1812+ that was just retired, 1813+, still going after almost 5 years and a new 3617xs and wondered what would happen if the box died. Never had any issues with any (knocking on wood).

@dustinb3403 said in Cross-Post Hyper-V and Backup recommendations:

My question is, should I also run backup agents (I use Veeam), on the Hyper-V environments and back them up as if they were physical boxes? Or is the daily backup fine.

General practice is to not back up the host itself. You should have a process to rebuild the host and, in theory, this should be incredibly fast and simple. Since restoring bare metal is always a pain because you have to get the restore going without an agent, rebuilding a nearly stateless host is generally faster and simpler and doesn't require storage and management.