As promised part 2 of a 2-part topic regarding rotating USB disks 
.
But after writing this topic I had to devide it 2 separate parts because of the limitation of 50.000 characters 
You can read the first part in OFFLINE backup copy using rotating USB disks – part 1 | Veeam Community Resource Hub
As already mentioned in part 1, using rotated USB disks is a possible and affordable way to have an offline or airgapped backup copy. If you keep them offsite, the two times 1 of the golden 3-2-1-1-0 has been completed!
In this part I will go a bit deeper in this topic.
I will split it into 4 sections :
- Limitations
When using a repository with the rotating drive option, you have some limitations you have to keep in mind. Those are :
- On one managed server, you must create only one repository with rotated drives
- It is NOT possible to store archive full backups (GFS) with backup or backup copy jobs
- It is NOT possible to use per-VM backup files
- It is NOT possible to rescan the backup repository
- NFS repositories do not support rotated drives
- A SOBR does not support rotated drives
- It is NOT supported to use as primary backup repositories, archive repositories and secondary target repositories for NAS backups
- How it works with Windows Server repositories
As example : we connect a USB disk to a USB3-port at a physical Windows Server that is used as a Veeam repository
In that way the USB disk will get a drive letter, for example it will be the E drive letter. It can be that the next time you will swap the drive it will get another letter because an ISO has been mounted between or so... When you use a Windows Server repository, Veeam can keep track of the drives even if the drive letter changes. Very handy !!!
But there is a requirement!
The first time you connect a certain drive, it must have the same path and drive letter as configured in the Veeam repository. This is a requirement for all the drives being used in the rotated cycle. The second time and later you connect this drive, the letter may change, Veeam will detect is as known and already been used.
Now it’s getting more complicated because there is a difference in how it works between a backup job and backup copy job.
Backup job :
Personally I NEVER use a backup job in combination with a rotated drive, because in my opinion it always has to be used as a secondary repository, so being used with a backup copy job. Also because the performance of a USB disk is lower than a repository consisting of more spindles and also less secure because of being a single point of failure and a NAS or local disks in a physical server is secured by using a RAID-mechanism.
But I will explain the working of it.
- VBR creates the first time of course a full backup file on the currently attached disk
- Afterwards it checks if the disk is consistent (full and all incrementals performed by the job)
If the disks has been swapped and missing a full and incrementals, it will create a new full that will be used as a starting point for the next incrementals
- The retention policy will be applied, so all backup-files that are outdated will be removed from the backup chain
REMARK : when you configure the job and set the number of wanted restore points, this number is the total of your wanted restored points across all disks.
For example : if you set 10 restore points and having a number of disks it will delete backup files on your disk when exceeding this number, it can be even the whole chain including the full backup file
I will explain further how I do that personally in using the copy job.
- When you swap drives again, VBR checks again the consistency and creates a new full backup
Be continued in part 3 …
. Thx 
