Always Full backup to tape

[patrickds]

Is there any way to always get a full backup on tape, even if the linked job has no new data?

We run daily and weekly jobs, forward incrementals.
There is a daily secondary backup to tape, with synthetic full, but this only writes data from the daily job, except on the weekend, when the weekly job has run.

For ease of restore from tape, and because there is a lot of remaining space on the tapes, we would like to have everything written to tape every day, even if that means the same data will be written every weekday between weekly jobs.
That way we know everything is available from every tape.

Is there any way to force this, apart from changing the weekly job into a daily?

[david.domask]

Hi patrickds,

Just to ensure I understand correctly, you have:

Job 1: Runs every day
Job 2: Runs once a week

Every day on tape, you want:

Current backup chain for Job 1
Current backup chain from Job 2, even if you're re-writing the same backup file each day

Am I understanding your tape-out strategy correctly?

File to Tape is the easiest answer here -- the restore narrative changes a bit as you need to pick specific files, but forcing full backups each day of the File to Tape job would meet your requirement. You can send File to Tape and Backup to Tape jobs to the same media pool, so you could consider a separate file to tape job writing to same media pool alongside the backup to tape job to meet this requirement, or similarly create multiple Backup to Tape jobs targeting the same media pool

[patrickds]

Job 1: Runs every day
Job 2: Runs once a week

Every day on tape, you want:

Current backup chain for Job 1
Current backup chain from Job 2, even if you're re-writing the same backup file each day

Exactly. Both full backups together are about 3.5TB, so space enough on Ultrium 8 tapes.

I've had a look at the files to tape backup, but that would change our backup strategy too much, adding an additional job just to get the weekly backup on tape. It would also mean the data gets read over the network, whereas now it goes from the backup-to-disk server to the tape-server over a dedicated 10Gb fibre.
I think we will just change the weekly job to run daily. These servers hardly change, so it will be a short window.

Another issue we've encoutered a couple of times now: we've had backup to tape jobs writing no data. 'No new files to backup per job setting', even though there was a new incremental backup since the last copy to tape.
Are incrementals, taken on the same day as a previous copy to tape, not considered as new backups for that day?

[david.domask]

> I think we will just change the weekly job to run daily. These servers hardly change, so it will be a short window.

Would work as well, and if you don't mind the backup workload on production for the incremental backup, then this will work quite well and avoid File to Tape.

> Are incrementals, taken on the same day as a previous copy to tape, not considered as new backups for that day?

We're talking about normal Backup to Tape, correct? Each run of the Backup to Tape job will compare what is in the repository to what is already on tape, and backup anything not on tape according to the tape job configuration.

It would be best to open a Support Case for the job runs when nothing was backed up and let Support review the debug logs. Export logs for the affected job, and Support will review and help understand why those sessions didn't back anything up.

[patrickds]

Just an update on this last issue.
I was in contact with support, who confirmed this as an issue in the algorithm that decides what to write to tape.
situation:
- backup to disk job 1 at 19:00
- backup to disk job 2 at 3:00
- both jobs copied to tape at 9:00.
- Every other day, there is no copy to tape for job 1, with a message 'no new restore points for this date'. The restore point on disk is not considered for copying to tape, because there already was a tape backup on the same day, even if the tape copy was made earlier (with data from the previous evening).
- The next day, it works correctly 'no restore point for this day, using the one from the day before'

A hotfix will probably be released.
As a workaround, you can schedule all jobs on the same day, with the tape copy last, but your backup window must allow for this.

[david.domask]

Hi patrickds,

Thank you very much for the follow up, glad to hear Support and RND were able to find the root cause and a workaround for the issue along with the long-term solution.

[jcalvetm]

The 'No new files to backup per job setting' Is the reason why we had to schedule our backups at 00:05 hours every day. The reason I was given was because that was the way it was designed -copying to secondary storage only worked with backups with the same date-.

So solution: launching copies after midnight or living with the fact of having one day difference between SOBR and tape.

At this time (after midnight), disk backups launch and once they appear on backup repo, they are copied to tape (configured as secondary target in backup jobs). We do a virtual full mo to fri (in fact tue to sat: tue 00:05h is monday's backup and so on) and incremental on sat and sun on the same friday tape.

Always depends on the volume and on your infrastructure. If you have an automated tape library, no problem at all, but if your tape unit is (manual) stand alone, you have to be aware that the whole process takes a long time (about 15 hours in our case), not counting that a human being has to change tapes (in office hours) and that Veeam is not aware of tape changes unless you inventory the tape library (unit) -we solved that using a powershell script running as scheduled task-, and also be aware that if a new dataset number is created on a tape with existing backups (dataset is overwritten), issues arise (as an error trying to recover backups from tape) -it seems this is fixed on latest versions-. Item mas, if a new (disk) backup for a server appears meanwhile the same server previous backup is being copied into tape (synthetic full), tape copy is interrupted and fails, so "old copy" has to be finished before new copy starts (for that server)- unless you check the "Prevent this job from being interrupted by source backup jobs". But then backup time can be eternal and tape capacity can be a problem.

So timing is important...