Backup direct to tape or backup copy files to tape

[CatSpirent]

I have a legacy tape backup system and software due to the variety of Unix OS (aix, hp-ux, and solaris) on standalone servers as well as older Linux systems not supported by VEEAM so that won't change, at least not in the near future.

I currently have my VEEAM backup server running backup copy jobs to my server that handles the tape backup. Since the backup copy jobs are on a schedule, they somewhat regularly have failures that get corrected next time the job runs.

My backup tape server then backs itself up thus backing up those backup copy files.

What is the greatest risk, or better practice, if you wish.

Continue as is, the backup copy files are reliable enough even with the interval window failures, or switch to installing my backup to tape software on the VEEAM backup server and just backing up the backup files directly to tape using my tape backup software.

When I transferred my VEEAM software to its own server, it took about 14 hours to transfer all the backup files to it, so I am assuming my tape backup process will take a similar amount of time for full backups every week, vs a much shorter time backing up the local backup copy files.

[Dima P.]

Hello Caterine.

Why not to use the built-in Veeam B&R tape functionality to backup your backup copy jobs (you can easily do that with backup to tape jobs which handles backup files perfectly and even creates synthesized full backup on tape from incremental restore point on disk whenever it's required)? You can backup the remaining files via file to tape jobs (if you cannot protect those via VM backup with Veeam B&R backup jobs)?

[CatSpirent]

I don't have a tape subsystem connected to my main VEEAM server.
Back when I had VEEAM installed on the same server as my main backup software, I tried enabling the tape on VEEAM.
It caused regular conflicts with my main backup software so I had to delete it.

[veremin]

- What kind of conflicts, can you elaborate?
- Are you copying whole backup copy chain each time?
- If not, how you address the problem with the oldest restore point (.vbk) being transformed regularly?

[CatSpirent]

I don't have a conflict.
I am just asking in general.

Currently I have my VEEAM server set to run a backup copy job after backup to a different server which also runs my legacy backup software which writes to tape for offsite storage.
I gather the VEEAM backup copy job does a synthetic full process because the disk space used is significantly less than on the VEEAM backup server.

I just want to know which has the greater reliability potential.
Continuing as is backing up the local synthetic fulls to tape for long term storage, or turning off the backup copy jobs and every weekend running a backup of my VEEAM server backup files directly considering the large amount of data that would be transferred over the network.

As I mentioned earlier, the seeding/setup of the backup copy jobs took about 14 hours so I am going to assume a direct backup of those backup files would take a similar amount of time.

I am still adjusting to having moved my VEEAM to a different server from my legacy backup server due to performance issues as it grew much larger than had originally been anticipated.

[veremin]

It caused regular conflicts with my main backup software so I had to delete it.

I don't have a conflict. I am just asking in general.

These sentences seem to contradict each other.

I just want to know which has the greater reliability potential.

Unfortunately, we cannot suggest knowing little what data you're backing up to tapes (backup chain as a whole, the oldest .vbk file, gfs restore point, etc.), how regularly and what results you're trying to achieve.

Thanks.

[CatSpirent]

These sentences seem to contradict each other.

The conflict occurred when VEEAM was installed on the same server as my other backup software.
Right now there is no conflict because I moved VEEAM to its own server and it has no attached tape subsystem.
The tape subsystem remains attached to the other server.

The data I am currently backing up are all the backup copy files that are on my other backup server using its software.
I gather those files are synthetic fulls created by the VEEAM backup copy process, is that correct?

If I were to switch to backing up the original files currently on the VEEAM server vs the backup copy files on my other backup server, I would only backup the respository directory.

Does that help?

[veremin]

The conflict occurred when VEEAM was installed on the same server as my other backup software.

Yep, those are the conflicts I was asking you about. What kind of issues did you have?

The data I am currently backing up are all the backup copy files that are on my other backup server using its software.
I gather those files are synthetic fulls created by the VEEAM backup copy process, is that correct?

Sorry, but it's still unclear what is selected as a job source, because you first mention "all the backup job files" and then you say "only synthetic fulls".

Can you choose one of the options that describes your tape job source best:

- backup chain as a whole (all backup files created by backup copy job)
- the oldest .vbk file
- GFS restore points (full backups created on weekly, monthly, quarterly and yearly basis; should have corresponding labels in their names - _w,_m, etc.)
- repository

Thanks.

[CatSpirent]

Yep, those are the conflicts I was asking you about. What kind of issues did you have?

Well the original conflict turned out to be IT instituting McAfee EndPoint security without really notifying key folks when they were putting into place on servers.
In trying to figure out why my backups were taking longer and longer to complete thus taking from 24 to 36 hours to complete I received recommendations that VEEAM really should be on its own server.
Considering how many VMs that were added over time it made sense.
I had already tried setting up the tape drive on VEEAM, but it interferred with my other backup software which was using the tape subsystem. Makes sense but was worth a shot at the time.
So my VEEAM server does not have a direct attached tape subsystem.
It backs up to local disks. When it was on the same server as my other backup software, it was easy enough to just back up the local disks.

Sorry, but it's still unclear

Sorry, I sometimes have a hard time trying to explain.
I have 3 backup jobs to try to separate the main job for most of my VMs, from the few that I occasionally have problems with which are also split between two jobs.
The schedule is fairly simple. Full once a week, incrementals in between.
They get backed up to local disk configured as the local VEEAM repository.
Attached to each of those main backup jobs are Backup Copy jobs. Those back up to the other VEEAM repository on the old server.
Those Backup Copy jobs I gather do synthetic fulls when they are copying the original backup files to the alternate server since the size of the files is usually smaller on my other backup server.

You mention GFS restore points with labels. I don't make it that complicated. I figure if I have to restore something from an older backup, once I restore the needed files from tape, I should be able to point VEEAM to them and start a restore process.
From there my other backup server backs up the all files on the disk which includes the Backup Copy files to tape.

[veremin]

Backup copy job uses forward forever incremental method, which means that the oldest restore point (.vbk) changes regularly. To have restorable backup chain on tapes you need to backup the oldest restore point .vbk, each time it changes (in most cases daily).

So, it stands to reason to switch to backing up source backup job, because it utilizes forward incremental mode with periodic fulls (the chain doesn't change in other words).

Thanks.

[CatSpirent]

Thank you, I will test switching to direct backup and see what impact it will have on my weekend backups.

[francs]

So, you use your legacy backup software to backup your Veeam vbk/vib files to tape?
It might not be the most efficient way of doing it, but you do have a copy and another offsite.
Off course, the only way to test backups is to do a restore. All the way from tape, importing it to Veeam and restoring a test file inside the original VM.

Is it not possible to split/partition the library?
I have partitioned an IBM TS3200 into 2 logical libraries, with 2 drives each. Connected 2 drives to my legacy backup server and 2 drives to my Veeam server.
This worked perfectly well and you can use the native Veeam tape functionality.

[CatSpirent]

I can see how I would do that with my tape subsystem, but I only have 3 tape drives and prefer to keep that many so I have no significant issues should one fail.
It hadn't occurred to me that the subsystem might have features to allow me to split it among multiple servers so I could add another tape drive or two.

I will have to see how generous management is feeling when EOY rolls around. Otherwise it can be difficult to obtain budget.

It is that time of year again to send my annual email of what I would like budgeted for next year.
It rarely changes since our available funding seems to be quite fluid every year with development taking a priority.