Storage arrays: hourly snapshots stored for 24 hours, daily snapshots stored for one week.

Longer term stored in veeam on a different array, those are taken daily and stored for 30 days typically. Sometimes longer archival copies if the business needs.

Bare metal usually daily

We also replicate all data live up to the cloud, for DR. (windows dfsr)

While it’s true that “It depends on your business needs”, most often I’ve seen backup schemes which work on a minimum of a daily backup of most data. For example, on a larger, busier system, it might have a full backup done over the weekend when the system isn’t as busy and therefore has a lower business impact. Then daily differential backups are done each night. For smaller systems, it might just be a full backup of critical data every night.

For highly active, critical SQL databases, I’ve also seen this extended where the a full backup was done of the database weekly, with differential backups done nightly and transaction log backups done every 15 minutes. This obviously had full transactional logging turned on for the critical databases.

As a concrete example, on my home “server” (desktop with delusions of grandeur), the main data partition is running on ZFS with snapshots taken every 15 minutes, hourly, daily, weekly and monthly. The 15 min. snapshots are kept for an hour. Hourly snapshots are kept for 24 hours. Daily snapshots are kept for 31 days. Weekly snapshots are kept for 8 weeks. Monthly snapshots are kept for 12 months. There’s a bit of overlap in the daily and weekly schedules, as those are most likely to cover my arse from an “oops” factor.

The downside of the snapshot setup is that it doesn’t provide disaster recovery. And, I’ll admit, for my home stuff I haven’t gotten around to sorting this out. Ideally, I should be taking a weekly backup, compressing and encrypting it and pushing it to a cloud service somewhere. Laziness has meant that hasn’t been done yet.

Backup on different levels, one of my clients who I would say has similar ifrastructure uses following approach:

• backup on the vm level - backing up snapshot of the entire virtualization guest - at least once a week, always before update/upgrade. These can be big - consider ZFS pool w/ compression and deduplication active - but that is also hw intesive. On the other hand, I don’t think you need to keep more than last two successfull backups.
• filesystem level - run rdiff-backup against the / of the filesystem several times a day. SInce it is essentially versioning, you are only backing up new changes. No zetabyte needed here, ext3/4 will do.
• drop database somewhere ideally several times a day - even if there are no incidents, your developers will love you.

The recovery strategy is as follows:

• pull the guest out of the last vm backup
• sync up the files from last rdiff-backup run
• discuss w/ the developer DB recovery - or just recover the last backup and hope for the best…

Most VMs backed up daily, depending on how vital then stored for anything from 3 days - 30 days. Few machines are backed up 3 times a week cause they’re tests servers and we’ll take snapshots as and when they’re getting actively used. Finally a couple of machines are backed up 6 hourly for data relevancy.

Everything replicated to a second backup server off-site and have a hardened repo for immutable backups.

@InternetCitizen2 daily snapshots of VMs and full backups before any updates and upgrades

Backup to a remote service. Make sure that the machine being backed up can’t delete or corrupt the backups