Discussions related to exporting backups to tape and backing up directly to tape.
Post Reply
MarkLomas
Novice
Posts: 6
Liked: 1 time
Joined: Jan 24, 2014 11:49 am
Full Name: Mark Lomas
Contact:

Trying to grasp tape...

Post by MarkLomas »

I'm having some problems with a customer site, and am struggling to understand what might be happening.

We're trying to 'prove' that the tape backup has a full backup of a particular key VM for the customer. We're encountering some gaps in the data when we restore, in as much that some volumes are missing.

The VM has approx. 9.4TB stored data. It's backed up first to disk using an incremental forever backup job (no period fulls synthetic or otherwise). 14 day retention.

The backup to tape job is a weekly, and is a backup to tape, not a 'files to tape' style job. According to the report of a recent successful backup, it transferred 9.4TB of data for this particular VM ... all good. When we select the most recent restore point against that job to restore back into the repository, we only get 2.7TB back. Now, I appreciate this may be de-duped and compressed size not 'real' size, but nevertheless we are missing certain volumes.

When I dig further, we see there are actually two restore points in the media set associated with this job, one for the 18/12/2015, and another for 27/11/2015.

As I understood it, a tape backup job would synthesize a full VBK file for the appropriate dates selected in the job properties, and that a single VBK would therefore be written to tape. This does not seem to be right though, as the jobs have two VBKs going to tape for each VM! What is happening here? Are we getting the 'original' oldest VBK, plus a rollup of all changes into a second VBK? I'm confused ... this is not the behaviour outlined in the documentation.

If someone can shed light on this I'd be hugely grateful. Here is a log output from the job;

Code: Select all

19/12/2015 04:16:13 :: No restore point for 19/12/2015 available for inclusion into synthesized full backup file, using previous restore point 
19/12/2015 04:16:13 :: New storage H:\Backups\BCOTDFS05_1\BCOTDFS052015-11-27T092608.vbk on This server was added to backup list 
19/12/2015 04:16:13 :: Synthesized VBK file will be added instead of storage H:\Backups\BCOTDFS05_1\BCOTDFS052015-12-18T193058.vib on This server 
19/12/2015 04:16:13 :: Creating synthesized VBK with state as of H:\Backups\BCOTDFS05_1\BCOTDFS052015-12-18T193058.vib 
19/12/2015 04:37:44 :: Queued for processing at 19/12/2015 04:37:44 
19/12/2015 23:57:11 :: New tape backup session started, encryption type is off 
19/12/2015 23:57:14 :: Processing full backups started at 12/19/2015 04:00:40 
20/12/2015 04:12:07 :: Tape BCT115L6 is full 
20/12/2015 04:12:10 :: Unloading tape BCT115L6 from Drive 0 (Drive ID: Tape0) to Slot 8 
20/12/2015 04:13:49 :: Loading tape BCT116L6 from Slot 7 to Drive 0 (Drive ID: Tape0) 
20/12/2015 04:14:54 :: Current tape is BCT116L6 
20/12/2015 04:15:09 :: Continue backup session: Backup set 19/12/2015 23:57:11 
20/12/2015 04:15:49 :: Backup completed successfully 
20/12/2015 08:33:29 :: Tape BCT116L6 is full 
20/12/2015 08:33:32 :: Unloading tape BCT116L6 from Drive 0 (Drive ID: Tape0) to Slot 7 
20/12/2015 08:35:07 :: Loading tape BCT119L6 from Slot 4 to Drive 0 (Drive ID: Tape0) 
20/12/2015 08:36:17 :: Current tape is BCT119L6 
20/12/2015 08:36:35 :: Continue backup session: Backup set 19/12/2015 23:57:11 
20/12/2015 12:51:04 :: No restore point for 20/12/2015 available for inclusion into synthesized full backup file, using previous restore point 
20/12/2015 13:08:58 :: Tape BCT119L6 is full 
20/12/2015 13:09:01 :: Unloading tape BCT119L6 from Drive 0 (Drive ID: Tape0) to Slot 4 
20/12/2015 13:10:21 :: Loading tape BCT120L6 from Slot 1 to Drive 0 (Drive ID: Tape0) 
20/12/2015 13:11:31 :: Current tape is BCT120L6 
20/12/2015 13:11:46 :: Continue backup session: Backup set 19/12/2015 23:57:11 
20/12/2015 17:34:16 :: Tape BCT120L6 is full 
20/12/2015 17:34:19 :: Unloading tape BCT120L6 from Drive 0 (Drive ID: Tape0) to Slot 1 
20/12/2015 17:35:46 :: Loading tape BCT140L6 from Slot 6 to Drive 0 (Drive ID: Tape0) 
20/12/2015 17:36:55 :: Current tape is BCT140L6 
20/12/2015 17:37:14 :: Continue backup session: Backup set 19/12/2015 23:57:11 
20/12/2015 18:21:49 :: Busy: Source 17% > Proxy 19% > Network 18% > Target 99% 
20/12/2015 18:21:49 :: Primary bottleneck: Target 
20/12/2015 18:21:49 :: Network traffic verification detected no corrupted blocks 
20/12/2015 18:21:50 :: Processing finished at 20/12/2015 18:21:50 
21/12/2015 15:06:17 :: Busy: Source 17% > Proxy 19% > Network 18% > Target 99% 
21/12/2015 15:06:17 :: Primary bottleneck: Target 
21/12/2015 15:06:17 :: Network traffic verification detected no corrupted blocks 
21/12/2015 15:06:17 :: Processing finished at 21/12/2015 15:06:17 
21/12/2015 15:06:17 :: 0 directories and 2 files backed up
Massive thanks in advance!
--
Mark Lomas
Shestakov
Veteran
Posts: 7328
Liked: 781 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: Trying to grasp tape...

Post by Shestakov »

Hello Mark,
Have you tried to restore the VM from the disk backup?

If VM size is 9.4TB, 2.7TB of backup size looks normal. Around same size should be written on tape. Virtual Full option should not harm restore from tapes.

I would suggest to contact Veeam technical support for faster issue investigation. Once you do, please post your support case number.
Thanks!
veremin
Product Manager
Posts: 20400
Liked: 2298 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Trying to grasp tape...

Post by veremin »

Also, make sure that tape retention is not shorter than a disk one. Otherwise, a tape job would try to copy two .vbks - old one that was copied previously but has been already removed from tapes and virtual full one. Thanks.
Post Reply

Who is online

Users browsing this forum: ikov and 20 guests