I've hit a very frustrating set of circumstances in trying to backup our Nextcloud DataPortal which is a very large VM of about 30TB onto LTO-9 tapes (for a truly offline airgapped set of backups). Due to the size, the backup requires at least 2 LTO-9 tapes in the media pool assigned to the backup.
The issues are:
PBS 4.2 doesn't seem to be able to handle the tape drive presenting a media condition during a job. For example, a cleaning cartridge was requested by the drive between tape 1 and tape 2. On insertion of the cleaning cartridge, it aborts the job.
If the source HDD based ZFS isn't quite fast enough to deliver chunks from the datastore at LTO-9 speed, and causes tape pauses, rewinds, shoeshining etc, and the tape hits a legitimate end of media condition, the capacity of the tape used before reporting full in PBS can be well beneath the 16.37TB uncompressed that it is supposed to be able to fill. This leads to there needing to be at least N+1 tapes in the media pool "just in case", because otherwise the job aborts with a tape allocation error.
My question is why aren't tape backup jobs pausable and resumable when media conditions are present? Why is it not possible to mid job, format and allocate a new tape into a media pool for a very large job to be resumable without starting from scratch and losing 2 days?
In fact, since I have 2 standalone drives in the same machine, why is it not possible to continue a job from drive 1 to a tape in drive 2? Why do you have to assign a drive to a media pool?
I've submitted a feature request for this type of stuff here: https://bugzilla.proxmox.com/show_bug.cgi?id=7660
Please add your support if you too are affected by what feels like a tape backup "afterthought" to an otherwise excellent product.
And no, sorry, we can't afford a tape library and autoloader.....
Thanks
Tino
The issues are:
PBS 4.2 doesn't seem to be able to handle the tape drive presenting a media condition during a job. For example, a cleaning cartridge was requested by the drive between tape 1 and tape 2. On insertion of the cleaning cartridge, it aborts the job.
If the source HDD based ZFS isn't quite fast enough to deliver chunks from the datastore at LTO-9 speed, and causes tape pauses, rewinds, shoeshining etc, and the tape hits a legitimate end of media condition, the capacity of the tape used before reporting full in PBS can be well beneath the 16.37TB uncompressed that it is supposed to be able to fill. This leads to there needing to be at least N+1 tapes in the media pool "just in case", because otherwise the job aborts with a tape allocation error.
My question is why aren't tape backup jobs pausable and resumable when media conditions are present? Why is it not possible to mid job, format and allocate a new tape into a media pool for a very large job to be resumable without starting from scratch and losing 2 days?
In fact, since I have 2 standalone drives in the same machine, why is it not possible to continue a job from drive 1 to a tape in drive 2? Why do you have to assign a drive to a media pool?
I've submitted a feature request for this type of stuff here: https://bugzilla.proxmox.com/show_bug.cgi?id=7660
Please add your support if you too are affected by what feels like a tape backup "afterthought" to an otherwise excellent product.
And no, sorry, we can't afford a tape library and autoloader.....
Thanks
Tino
