Tapes bound to jobs

[jim_mcguire]

Is there any way to bind a tape to a job?  For example, I have 5 tapes named 'Monday' through to 'Friday'.

If Monday's tape is left in on Tuesday, the backup job scheduled to run on weekdays will simply append to Monday's tape. Is there anyway I can prevent this so that only Monday's tape is used on Monday and Tuesday's used on Tuesday, and the scheduled job just fails if the correct tape is not present?

Many thanks,

Jim

[Possible]

Create 5 volume pools and always make sure there is a tape available in that pool.

[CraigV]

Hi Jim,

The only way to do this is to use a library/autoloader with partitions. You would then direct specific jobs to specific slots which ensures that tapes in these slots can only be used by these jobs.

However, if a job needs to span to an additional tape, and no tape exists, the job would either fail, or queue so bear that in mind.

Thanks!

[CraigV]

...I assume you're talking NBU talk here right? BE does things differently. Creating a media set is no guarantee that a tape will stay in that particular media set.

if a tape is overwritable, it is then available for any job. This is how BE utilises its media.

Thanks!

[jim_mcguire]

Thank you both.

[Possible]

I was talking for nbu..nevermind :)

[Larry_Fine]

If Monday's tape is left in on Tuesday, the backup job scheduled to run on weekdays will simply append to Monday's tape. Is there anyway I can prevent this so that only Monday's tape is used on Monday and Tuesday's used on Tuesday, and the scheduled job just fails if the correct tape is not present?

If you are using a single stand-alone tape drive (ie not a robotic library), you can use media set rules to prevent the Tuesday backup from appending to Monday's tape.  If you set the append period of the media set to something short (like 12 hours), then the Tuesday backup could not append to Monday's tape.  You can set the overwrite protection time to something like 6 days, which will prevent Tuesday's backup from running and the job will fail or sit and ask for you to insert overwritable media.  Or you can set the overwrite protection short (like 6 hours), and that way the Tuesday backup would overwrite the Monday backup.

[CraigV]

...the assumption here is that the tape is still left in the drive, and has not been ejected or manually removed...?

Thanks!

[Larry_Fine]

Yes, that is my assumption because if Monday's tape is not still in the drive, then it is not possible to append on Tuesday, and it was the OPs desire to avoid appending.

So, one method to satisfy that desire to avoid overwriting is to schedule an eject after Monday's backup, but I assume that might not be diesired (for unexplained reasons).

The key to this is to clarify if the OP has a stand-alone drive or a robotic library.

[jim_mcguire]

Thanks Larry,  I have the job set to protect for 6 days, however I think that is only attributable to the data that is written not to the tape as a whole.

There is no appendable option in BE2014 although I was sure this existed in BE2012?

[Larry_Fine]

I see that Jim has two threads going, the other one is about an RDX drive, which is a "disk cartridge", not a tape.

"disk cartridge" doesn't use the traditional overwrite and append timers that tapes do.

Therefore, Jim, what is your hardware environment?

[jim_mcguire]

Environment is:

Win 2k12 Standard Server running on ESXi 5.5 host on a X3650 physical host with Quantum RDX-USB3 attached via USB3 passthrough.

[CraigV]

Jim: A virtualised media server is not supported when accessing a physical device like tape/RDX. Might be your issue...I would suggest logging a call with Symantec to see what sort of support you might get from them.

Thanks!

[jim_mcguire]

Environment is:

Backup Exec 2014 (14.1)

Win 2012 Standard Server Guest OS running on ESXi 5.5U1 on a X3650 physical host. 

Quantum RDX-USB3 attached via USB and using USB-passthrough to the VM.

[jim_mcguire]

Thanks Craig, can you point me to the documentation which confirms this as the only thing I can find is dated 2012 and is referring to either BE2012 or BE2010, wondering if the situation has changed in BE2014?

[Larry_Fine]

I don't think anything significant changed in BE 2014 in this area.

However, the bulk of this thread was predicated on the use of actual tapes, and therefore the discussion was around overwrite and append times, etc.

Since we now know that you are actually using disk cartridge, I don't think there is a way of preventing Tuesday's backup from writing to the same cartridge that was used for Monday's backup unless an eject was done and Monday's cartridge is physically not available.

Since it looks like the "eject after backup completes" is missing from BE 2014, the workaround would be to run a scheduled eject job for mid-morning (or sometime after you are sure your backups are done).

[CraigV]

No Jim, that would be relevant to BE 2014 as well, and it is more of a support issue with VMware than BE itself.

I saw nothing in the release notes around BE 2014 now being supported to run on a VM and connecting to physical devices.

Thanks!

[jim_mcguire]

Do they implement this intrinsically in tape? I'd have imagined it would simply be a piece of metadata written to the tape/cartridge which says do not overwrite me until x. Why so much emphasis on the medium used?

[Larry_Fine]

I'd have imagined it would simply be a piece of metadata written to the tape/cartridge which says do not overwrite me until x.

With disk, that level of control is down at the backup set level, not at the cartridge level.

Disk & tape are fundamentally different.  Tape is sequential and disk isn't.  With disk, you can essentially remove one backup set from the middle of multiple sets, but you cannot do that with tape.

[pkh]

Since BE 2014 SP4, RDX cartridges are managed by DLM which means that how the backup sets are deleted is changed.  Media sets no longer applies. See these

http://www.symantec.com/business/support/index?page=content&id=TECH214945

http://www.symantec.com/business/support/index?page=content&id=TECH214948

https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012

https://www-secure.symantec.com/connect/articles/when-backup-sets-are-deleted-under-dlm