FR: Space Requirements for Backup Copy Jobs to rotated disks

[jim3cantos]

Hello:

the space requirements indicated in KB2207 seem a bit impractical, at least for backup copy jobs to rotated "local" disks. We are not going over a WAN in this case. It should be good to have an option for writing the VIB incremental data directly into the VBK full like local backup jobs (in fact I think that sometimes it really does the merge that way, may be when the incremental backup file to merge is small?). Another option could be to be able to create rotated disk repositories with "Per-VM Backup Files" option but this isn't allowed either.

thanks

[foggy]

Could you please elaborate on what requirements do you find to be not practical?

It should be good to have an option for writing the VIB incremental data directly into the VBK full like local backup jobs (in fact I think that sometimes it really does the merge that way, may be when the incremental backup file to merge is small?).

Not sure I understand this part as well. Do you mean the reverse incremental backup method used in the backup jobs, where the changes are injected directly into the full backup file?

[jim3cantos]

Could you please elaborate on what requirements do you find to be not practical?

I refer to the "merge overhead" indicated in the KB when the destination of the backup copy job is a rotated disk (no WAN, no connection issues). In our case, the full backup file size is 1.2 TB and the incremental is around 30 GB (we only store one incremental per disk, the minimum). What we find not practical is to need a 3TB disk for this case when backups should fit nicely in a 2TB disk.

Not sure I understand this part as well. Do you mean the reverse incremental backup method used in the backup jobs, where the changes are injected directly into the full backup file?

I think so but in fact we use the incremental (recommended) method for backup jobs. Isn't the situation the same in this case?, i.e. the changes of the oldest incremental backup are injected directly into the full backup file?

[foggy]

I refer to the "merge overhead" indicated in the KB when the destination of the backup copy job is a rotated disk

The KB is simply wrong. temp file is not used during merge of increment into full backup file, changes are merged into the full directly (temp file is used in case of GFS and compact operations, though).

I think so but in fact we use the incremental (recommended) method for backup jobs. Isn't the situation the same in this case?, i.e. the changes of the oldest incremental backup are injected directly into the full backup file?

With the forever forward incremental backup method, the oldest increment is merged into the full backup file, right. However, in case of rotated drives, backup copy job implements retention algorithm differently, depending on the backup repository type.