Trying to grasp tape...

Everything about backing up to tape

Trying to grasp tape...

Veeam Logoby MarkLomas » Wed Jan 06, 2016 3:43 pm

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
MarkLomas
Novice
 
Posts: 6
Liked: 1 time
Joined: Fri Jan 24, 2014 11:49 am
Full Name: Mark Lomas

Re: Trying to grasp tape...

Veeam Logoby Shestakov » Thu Jan 07, 2016 10:29 am

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!
Shestakov
Veeam Software
 
Posts: 4856
Liked: 394 times
Joined: Wed May 21, 2014 11:03 am
Location: Saint Petersburg
Full Name: Nikita Shestakov

Re: Trying to grasp tape...

Veeam Logoby v.Eremin » Fri Jan 08, 2016 11:45 am

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.
v.Eremin
Veeam Software
 
Posts: 13266
Liked: 968 times
Joined: Fri Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin


Return to Tape



Who is online

Users browsing this forum: Google [Bot], MBT and 10 guests