Run Manual Maintenance Tasks on Backup Disks

[JamesF2]

I was wondering if there is a way to run a manual one time maintenance tasks on a disk copy without having to schedule these within a job. Tasks like a 'health check', 'Defrag and compact', Remove Deleted items. Maybe even create a synthetic full backup. I would rather not have to modify jobs and try to figure out schedules and only run them when I want to.

Perhaps Veeam could even add a notice on the disk to indicate a disk copy that would benefit from these tasks, or at least show the information within the backup disk properties.

[HannesK]

Hello,
and welcome to the forums.

For health checks, you could use the validator tool. The other operations are tied to the backup job.

What's the reason you want to do these operations manually? That sounds like a lot of work for hundreds or thousands of machines.

Best regards,
Hannes

[JamesF2]

Thanks for the info on the validator tool. I don't know how often the maintenance tasks will need to run, and I'm sure it will vary per job. Scheduling changes take time as well. And, keeping track of how the schedules are staggered is also an issue since I have to go into each job and try to correlate which tasks run on different jobs on which week/month. to me that also is a lot of work. I'm looking to only run it when it needs it.

[HannesK]

did you see any issues with the default settings? What type of storage are you using and which backup mode do you have configured? If you use a recommended setup (meaning XFS / REFS file system), then only health checks create high load (and they can be scheduled independently to run them outside the backup window). For everything else, there should be no need to change schedules or do anything manually.

[JamesF2]

We generally use a Synology NAS via SMB as the storage, most of those are probably using BTFRS locally on the NAS. Backup modes are Incremental. We haven't had any chain issues with Veeam or corruption of the backups (knock on wood). We do have jobs that have changed by adding or removing a VM, so we want to reduce bloat in the backup disk set. We also are not sure if there would be any performance gain on some of the jobs, particularly related to merge time, if the disk set had a defrag and compact job (or a synthetic full) executed on it. And yes, we do not want to add delays to job processing during the backup window with maintenance tasks that could be running during the day without competing for resources on the proxies and NAS, or generally waste resource usage to run tasks that are not needed either. That is why we are trying to find out if the backup disk set that is related to a job would first benefit a task to be run, and then be able to run it only as needed.

[HannesK]

SMB is the worst option when it comes to synthetic fulls. Moving to a system with fast clone support (iSCSI in your case) would make it many times faster (something between 10-50x usually)

[JamesF2]

That is good to know about SMB. Hopefully, the Synology's implementation of File Fast Clone on the BTFRS file system is reducing that some.

[HannesK]

BTRFS fastclone is irrelevant. it's about REFS or XFS running on the Veeam repository server. The Veeam repository server then connects to Synology with iSCSI

[BackupBytesTim]

To elaborate slightly on that (from my probably not perfect understanding) in order for Fast Clone support in Veeam to function, the Veeam repository server needs block level access to the actual storage location. SMB only shares files with connected clients (whether the "client" is Windows Explorer, Veeam, or anything else) so the Fast Clone feature simply can't function. When using iSCSI (simple explanation) you're essentially plugging the physical drive into your repository server, but over the network, so the operating system on your Veeam server configures the file system, such as Windows with REFS, and the Veeam repository server itself has block level access, which then would enable features like Fast Clone.

If anyone knows any of that to be inaccurate let me know, I'll admit to not having regularly used iSCSI in a production environment.