Skip to main content

The sequel of part 2 😉

And it seems that a part 4 is also needed 🙄

 Backup copy job :

  • VBR creates the first time of course a full backup file on the currently attached disk
  • When you swap the disk and if it is empty, it will create a full backup on it

If there is a backup chain on it for this job, it will create a new incremental in the current chain. The latest incremental is the start point of the new incremental

  • The retention policy will be applied, so all backup-files that are outdated will be removed from the backup chain

Because I always use a backup copy job in combination with rotated drives as a offline/airgapped solution I always recommend the customer to swap the disks on a weekly basis. Therefore I mostly configure the job with 7 to 10 restore points meaning 1 full and 6 to 9 incrementals.

I don’t care about the total wanted restore points, I see the number of restore points per disk. I tell you later why.

Normally the disks chosen are having a capacity of +/- 2 times a full backup.

The number of disks is at least 3 but recommended 10 as already mentioned in part 1.

So what will happen in the scenario of 7 restore points and 3 disks :

  • Disk 1 is inserted
  • Full is created on the first day of the week
  • Incrementals are created for the next 6 days, so no merges will be done, we have 1 full and 6 incrementals on the disk and still room for certain incrementals if needed (if the number of restore points is set higher than 7)
  • The disk is swapped in normal circumstances after 7 days
  • The same will begin on disk 2 : first a full and 6 incrementals
  • After a week the disk is swapped
  • The same will begin on disk 3 : first a full and 6 incrementals
  • Next, disk 1 is inserted and already has a chain on it but in total we already have more than 7 restore points over the 3 disks : so the whole chain will be deleted on disk 3 and will begin again with a full and incremental

 

Personally I would like to have the opportunity to go further with the existing chain and create a new incremental. Sure, that can be easily by changing the number of restore points to 30 or so, than it will create new incrementals.

 

But what will happen if the customer doesn’t swap the disk, it will create more incrementals on the disk than wanted and having no spare storage anymore and then the ... hits the fan.

Why, extra costs for creating an incident case, ...

Also when a lot of merges are done on the full backup file, it’s getting fragmented and is also getting bigger. I know you can enable the maintenance in the job, but already mentioned it’s only a USB disk. Therefore I chose to have a sequential writing without a lot of transformations and so.

It ‘s the most stable way to do this in my opinion.

 

To be continued …

 

 

Very nice part 3. 👍🏼


The sequel of part 2 😉

And it seems that a part 4 is also needed 🙄

 Backup copy job :

  • VBR creates the first time of course a full backup file on the currently attached disk
  • When you swap the disk and if it is empty, it will create a full backup on it

If there is a backup chain on it for this job, it will create a new incremental in the current chain. The latest incremental is the start point of the new incremental

  • The retention policy will be applied, so all backup-files that are outdated will be removed from the backup chain

Because I always use a backup copy job in combination with rotated drives as a offline/airgapped solution I always recommend the customer to swap the disks on a weekly basis. Therefore I mostly configure the job with 7 to 10 restore points meaning 1 full and 6 to 9 incrementals.

I don’t care about the total wanted restore points, I see the number of restore points per disk. I tell you later why.

Normally the disks chosen are having a capacity of +/- 2 times a full backup.

The number of disks is at least 3 but recommended 10 as already mentioned in part 1.

So what will happen in the scenario of 7 restore points and 3 disks :

  • Disk 1 is inserted
  • Full is created on the first day of the week
  • Incrementals are created for the next 6 days, so no merges will be done, we have 1 full and 6 incrementals on the disk and still room for certain incrementals if needed (if the number of restore points is set higher than 7)
  • The disk is swapped in normal circumstances after 7 days
  • The same will begin on disk 2 : first a full and 6 incrementals
  • After a week the disk is swapped
  • The same will begin on disk 3 : first a full and 6 incrementals
  • Next, disk 1 is inserted and already has a chain on it but in total we already have more than 7 restore points over the 3 disks : so the whole chain will be deleted on disk 3 and will begin again with a full and incremental

 

Personally I would like to have the opportunity to go further with the existing chain and create a new incremental. Sure, that can be easily by changing the number of restore points to 30 or so, than it will create new incrementals.

 

But what will happen if the customer doesn’t swap the disk, it will create more incrementals on the disk than wanted and having no spare storage anymore and then the ... hits the fan.

Why, extra costs for creating an incident case, ...

Also when a lot of merges are done on the full backup file, it’s getting fragmented and is also getting bigger. I know you can enable the maintenance in the job, but already mentioned it’s only a USB disk. Therefore I chose to have a sequential writing without a lot of transformations and so.

It ‘s the most stable way to do this in my opinion.

 

To be continued …

 

 

Next, disk 1 is inserted and already has a chain on it but in total we already have more than 7 restore points over the 3 disks : so the whole chain will be deleted on disk 3 and will begin again with a full and incremental

 

I have a question on this part, if disk 1 or 3 files will be  deleted ?  Here disk 3 is mentioned, but disk 1 is inserted , so full and incremental will happen in disk 1 , right ?


Hi @Nikks , it’s a typo disk 3 has to be disk 1. I hope that answers your question or remark...


Comment