This is all great advice and is exactly the process I use in customer migrations or disaster recovery.
Since you’re doing this on a regular basis I’d just add a couple of tips on performance.
If you’re using Robocopy to sync the root server directories between servers, it can go dramatically faster with the multithread option ( /MT: ). By default robocopy uses 8 threads at a time, but /MT:16 or /MT:32 can be dramatically faster as it must copy millions of very small files. This doesn’t help though with copying the SQL databse backups (that are just a few very large files).
If you use the Task Scheduler to run your Robocopy on a regular basis, the Task Scheduler runs the copy in a lower priority that can take much longer. The only way I’ve found to make the Task Scheduler run in a normal priority is to create the copy task, export it to XML, edit the XML directly, and re-import the XML as a new task. There’s a bit of description to this at https://stackoverflow.com/questions/47197821/how-to-change-default-scheduled-task-process-priority-in-windows
Also, check that SQL Server is configured to compress your database backups. I’ve seen cases where the database backup is 800 GB but with compression goes down to about 150 GB, for a much faster copy between the servers. Even at that size, compressing the backup only adds 10-15 minutes to the backup time but can save hours in copy-over-the-WAN time.