Best practice for moving VBR server components from single HDD disk to separate SSD disk

You cannot "migrate" things from one drive to another.  It would require a reinstall to point to the new drive.  You can backup the SQL DB and restore after moving the install then install Veeam and point to the DB again.  Or do a configuration backup, uninstall, reinstall to new drive and restore configuration backup.  There is no migration path here.

As Chris noted ​@NemanjaJanicic ...not much you can do, aside from adding the SSD and migrating the VM (storage migration in Hyper-V?) to the SSD. The only other thing you can do is add a 2nd disk and move Logging to it. You can do this by using the following Veeam KB:

https://www.veeam.com/kb1825

You may be better served by creating a new DS on SSD, vmotion-ing the VM storage to it, followed by extending the VMDK & finally the C drive. The Hyper-V process would be similar in nature. 

Have you considered just making your virtual disk bigger and using windows disc management to expand the volume. 

Your idea of adding an SSD-backed disk and relocating Veeam components could be aligned with best practice.

The next question two answers 

What should you move to the new SSD disk?

my thinking is

Document a roll back plan and validate if rollback is required at each stage in process. Don’t be afraid to undo. 

1. Veeam SQL database (depending on version Postgres SQL/SQL Express/Sql (std/enterprise)
2. Veeam Backup Catalog
3. Veeam logs
4. Veeam configuration backup

How you go about this the complex process. 
This evolves multiply step with some stepping depending on other competing without error before you start the next one. 

• Stopping and starting service  {inculding backup/ replication jobs}
• Stopping, detaching, moving database, reattaching and starting database.
• Moving file and folder between volumes 
• validation that everything still works.
  
  You can either do it step by step manually or running power shell, the PowerShell command might sight different between windows versions. (don’t just trust chatgpt to give to your correct commands) test and validate. everything.

Known pitfalls to avoid

Don’t do this

• Moving SQL files without detaching the DB.
• Editing registry paths manually unless explicitly required
• Leaving catalog/logs on slow HDD when SSD is available
• Forgetting NTFS permissions on new disk
• Snapshotting during DB move

Things to watch

• Antivirus exclusions must include new paths
• Ensure the Veeam service account has full control on V:
• If using local SQL express, make sure SQL tempdb isn’t starving on C:
• [SQL express] Keep at least 10–15 GB free on the SQL volume at all times

Resulting recommended layout (example)

C:\

├─ Windows OS

├─ Veeam binaries

V:\ new volume SSD

├─ VeeamSQL\

├─ VBRCatalog\

├─ VeeamLogs\

└─ VeeamConfigBackup\

A Veeam Configuraiton Migration is probably best here. Spin up a new VM with desired specs / hardware configuration, install Veeam (same version), ensure this server can reach the remote components (proxies, repositories, etc), and then copy the latest BCO (configuration backup) to the new server and perform the migration. You would turn the original server off when starting the migration to avoid conflicts.

This leaves original Backup Server VM “alive” and recoverable if there are unexpected issues with the migration.

As for where to place what, I would leave it on default (C:\) and just expand the disk.

You can certainly install the database engine to a second drive and then restore the configuration backup to that engine, there is no specific best practice here as long as the Backup Server can communicate with the configuration database.

Logs can also be pointed to a different location but please note that some Veeam services will always write to the system volume, typically these do not produce high amounts of log churn however.

But for the rest, I would keep it on system volume.