Jump to content
Joriz

Asking for new media... and other issues.

Recommended Posts

Hello all,

I'm working for a company some time who are using Retrospect for mac to backup projects. I've been working with other backup software before like veeAM, Symantec backupexec which worked great, while Retrospect is pulling my hairs out...

I have so much issues with this software and i don't know why. It seems all very unlogical to me if i compare it with software like veeAM and backupexec. I if could switch to other software i would do that for sure...

Issues:

  • I backup from all kind of servers. They all have their data shared over the SMB protocol which are added as source in Retrospect. Backup data from 1 server is working fine but it's so slooow, like 2.3GB/m. While a manual file transfer of the same source is utilizing the 1Gbit network card... The library is a LTO7 connected over a SAS interface. Why is it so damn slow ?
    While running a backup of a FreeNAS server over SMB, the backup job often just fails (error: Execution incomplete, !Can't read state information, error -1.101 (file/directory not found)). Why? 

 

  • Retrospect is asking for new media while it doesn't have to. For example i'm backing up a project of around 21TB and it asked me for a 5th tape today. A LTO7 tape is compressed around 14TB and native around 6TB. Why ?
  • Similar issue when running an offsite backup to tape. Retrospect asked for a new LTO7 tape after copying only 100GB of data while the complete backup was around 4TB.. Why ?

 

  • I'm trying to automate my offsite backups during the weekend so i made scheduled jobs for that. It's look not possible to simply overwrite the tape everytime. How do i do this?

 

The Retrospect version i'm running is Retrospect v16.1.2
The machine specs are:

- OS X El Capitan version 10.11.6
- Mac Pro Early 2008
- CPU 2 x 2.8 Ghz Quad core Xeon
- 8GB memory
- 2 x 2TB of storage

 

Share this post


Link to post
Share on other sites

Sounds like you've got problems with the library/drive. What make/model is it?

I try to use Retrospect Client on the source servers rather than SMB-mounting them onto the Retrospect server since I find it generally works better -- an interrupted/resumed SMB session is usually handled fine during, say, a Finder copy but can be death to a backup.

Otherwise, try the usual troubleshooting: how fast is a Retrospect Server to tape backup (i.e. eliminating SMB from the problem); how fast is a backup of SMB-mounted share to a disk directly attached to the Retro Server (i.e. eliminating the tape drive), and so on.

For best speed you may want to look at a disk-to-disk-to-tape setup...

As to overwriting tapes -- we don't do that here but, IIRC, that's what the "Recycle Media Set" media action (in the "Schedule" pane of the script definition) is for. Or have you tried that and found it doesn't work?

  • Like 1

Share this post


Link to post
Share on other sites

Joriz.

First I suggest you read this April 2019 thread—the whole thread all the way through the final post.  The OP in that thread discovered that he was backing up a lot more data than he thought he was.  He also found the data was mostly pre-compressed, so that what really mattered was the native capacity and speed.

Second, the OP in that thread also found that the tape library was never cleaning its heads—so he was getting un-recoverable errors after only a fraction of a particular tape was used.  Your "backup server" machine is quite old; are you sure whoever was responsible for it before didn't just cable-up a new tape library without finding out how to set up head cleaning?  That's one reason why Nigel Smith asked the make/model question.  See pages 50-52 of the Retrospect Mac 16 User's Guide for instructions on how to set up  cleaning for libraries and drives.

Third, you write "a manual file transfer of the same source is utilizing the 1Gbit network card".  That sounds as if there might be more than one network card on either your "backup server" and/or your SMB-attached source machine—which brings up another set of questions.

After you've looked into those questions, I would suggest you phone U. S. Retrospect Technical Support at (925) 476-1030; the people on these Forums are just volunteers like me‬.  If your organization installed Retrospect Mac 16 within the past 30-45 days, you are entitled to free personalized support.  Because it sounds as if your native language is not English, and because you posted so early in the morning even compared to New York time, it seems that you may be located in Europe.  I've heard that European Retrospect Tech Support is handled by a contractor, whose personnel don't know that much about Retrospect (probably especially about Retrospect Mac).  May I suggest you put your Location in your Forums profile?

Edited by DavidHertzberg
Fixed first two sentences in second paragraph, because tape drives get their _heads_ cleaned—not their tapes; add new sentence to paragraph on how to set this up
  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, Joriz said:
  • Retrospect is asking for new media while it doesn't have to. For example i'm backing up a project of around 21TB and it asked me for a 5th tape today. A LTO7 tape is compressed around 14TB and native around 6TB. Why ?
  • Similar issue when running an offsite backup to tape. Retrospect asked for a new LTO7 tape after copying only 100GB of data while the complete backup was around 4TB.. Why ?

"Source Speed: The speed of the source volume is the single most important factor in determining streaming tape capacity. Each time the buffer in the drive runs out of data to copy, an "underrun" occurs and unused tape streams on by, wasting raw tape capacity. The more underruns, the greater the reduction in capacity."

https://www.retrospect.com/au/support/kb/tape_capacity_faq

For an offsite backup, you really should perform a disk-to-disk-to-tape backup (as already suggested).

Share this post


Link to post
Share on other sites
50 minutes ago, Lennart_T said:

"Source Speed: The speed of the source volume is the single most important factor in determining streaming tape capacity. Each time the buffer in the drive runs out of data to copy, an "underrun" occurs and unused tape streams on by, wasting raw tape capacity. The more underruns, the greater the reduction in capacity."

Which is another reason for asking about the drive make/model. LTO drives are clever and slow down the tape speed to try and match the data rate but even then there's a minimum speed and, at rates below that, underrun occurs.

Although, at only 100GB on an LTO7, that sounds more like an interrupted transfer -- RS is interpreting it as a tape error, considers the tape done with (though the data is safe up to that point), and asks for another tape so it can carry on. I get similar with my not-really-supported Thunderbolt to Fibre Channel adapter...

Share this post


Link to post
Share on other sites

Thanks for the replies. It's correct that i'm located in Europe. My english is not perfect but i'll do my best.
I currently have a backup job running which i don't want to cancel, so i can't answer the troubleshooting related replies right now.

About the age of the mac pro machine. I know it's old but it still should be able to backup data to an LTO drive. It's not very a demanding thing to do. When a job is running the cpu load is below 20% and the machine is not running out of memory as it is only being used for Retrospect.

I prefer to use the Retrospect client as well but in my case it is not possible because the backup sources are FreeNAS/FreeBSD or HP based storage machines. I have 1 Windows 10 machine running which is using the Retrospect client to write the veeAM backup files to tapes. This is the machine/source where the backupjob was asking for a new tape after only 100GB of copied data.

The LTO drive make/model we use is an Overland Neo T24. It's a 24 slot library with a LTO7 drive. The library is connected to the mac pro with a SAS cable. The HBA we use in the mac pro is an ATTO H680 6Gb/s SAS interface. The interface is running the latest firmware/drivers.

The library is 12 months old and in Retrospect i have a cleaning slot configured. As far as i can remember, Retrospect initiated 3 cleaning jobs during the last 12 months.

 

 

Share this post


Link to post
Share on other sites

Given the above, it looks like a good test would be to compare the transfer of the veeAM files from the Windows client to a) an hard drive directly attached to the Retro server, and b) to tape. While everything looks good I'm starting to wonder if you've got a dodgy SAS cable or something. Would also be worth turning off the speed-enhancing features on the ATTO card, if you haven't already -- you hardly need them for this.

As to cleaning -- you've done that far more often than I have! LTO is largely self-cleaning so, unless the library is in a dusty environment, you could get away with turning auto-cleaning off entirely and just doing it manually once a year or when you start seeing tape errors.

But I'd still look at going D2D2T. Retrospect -- indeed, most backup solutions I've tried -- hate doing lots of small files to tape, especially when those files are on a mounted share. There's a lot of overhead for each file so you aren't using the tape drive optimally. You may even find D2D2T faster, if you can run multiple backup sets and your Mac Pro has the throughput to back up clients to Set A whilst also copying from Set B to tape...

Share this post


Link to post
Share on other sites

Joriz,

Nigel Smith is correct about self-cleaning of LTO drives.  (I recently re-started backing up my old G4 Digital Audio Mac to a DAT drive after 4 years, because Retrospect Mac 16 eliminated the ability to back up PowerPC "clients" over the LAN, but DAT isn't self-cleaning—so I let Retrospect Mac 6 remind me to use a cleaning cartridge.)

Every Saturday morning I do a Recycle backup of two sources, one an HDD and one an SSD, that are internal to my 2010 "cheesegrater" Mac Pro "backup server"—a somewhat-faster version of your 2008 Mac Pro.  They both back up (copying phase) at around 2.2MB/minute.  That's the almost the same disk-to-disk speed as with AFP shares as sources, per the fourth paragraph of this 2010 post.

Because I started using Retrospect in 1995 to back up to a rather-unreliable tape drive, and because the Saturday script also does a LAN backup of a MacBook Pro "client", out of excessive (because my destinations are now portable USB HDDs) caution I continue to let my Recycle script's Options->Backup default to Thorough Verification.  For internally-attached drives that means byte-by-byte  comparison, which takes just about as long as the copying phase. Although pages 97-98 of the Retrospect Mac 16 User's Guide don't say so, I believe that drives that are connected to the "backup server" via SMB are treated as if they were internal (this section of an ancient Knowledge Base article seems to imply that by saying "If you back up a mounted AFP volume using the method listed above, privileges are not preserved and can not be restored. The only way to back up and restore privileges from a volume over a network is to back up the computer using Retrospect Client Software.") .  You may want to live a bit dangerously :rolleyes: and change your Options->Backup to Media Verification, or even—because your tape drive is LTO with built-in verify-after-write—to No Verification.:o  Either of those changes—if you haven't made them already— should speed up your Backup script's total execution time by shortening/eliminating the verification phase.

 

Share this post


Link to post
Share on other sites

Joriz,

Veeam won't back up directly to tape; you have to do a tape backup of the output of Veeam disk backup jobs.  Since each of those jobs creates lots of small files in a Veeam repository, when you use Retrospect to back up a repository directly to tape you are writing to the tape inefficiently.  Therefore you should be using disk-to-disk-to-tape, as Lennart_T and Nigel Smith suggested.

If you ever used BE (you named the product in your OP, but I don't want to upset the head of Retrospect Technical Support by naming it again) to backup to tape, I think you were actually using disk-to-disk-to-tape.  BE makes it extremely easy to set up a D2D2T operation with templates.

Edited by DavidHertzberg
Rewrote post with same message: Veeam-repository-to-tape _directly_ is backing up lots of small disk files; BE-to-tape, if you ever used it, was probably doing D2D2T

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×