Jump to content
Sign in to follow this  
jweisbin

backup one server to another - question

Recommended Posts

I want to backup my main file server to another server running Retrospect 9.0.1. My question is: is it better to simply attach Retrospect to the other server's individual share points (as shares) and back them up, or is it better to install the "Client" on the server to be backed up and have Retro back it up that way.

 

If I remember, the Retro Client doesn't allow you to easily pick and choose what folders to be backed up and which to exclude - am I wrong about that?

 

Are there other benefits or down sides to either method?

 

Thanks in advance.

Share this post


Link to post
Share on other sites

The retro 9 client doesn't directly allow you to specify what folders to back up -- the engine sources would be used for that. But the client can mark folders "private" from the backup.

 

From testing I did ages ago, I found it was faster to use the source mounted than to back up something via client. But, really, that was years ago when I tried that. For all I know, it's not faster any more to do it that way.

 

 

You didn't say if this was a one-time backup, or if it was an ongoing backup of incremental data, etc. If on-going, I'd probably use whatever was faster *first*, then let the client do incremental backups so you don't have to worry about the drive being mounted, etc. (if that's what works faster the first time...)

Share this post


Link to post
Share on other sites

If it were me, I'd just let the client do the work -- unless there was such a large incremental amount of data to be backed up that the "mounting" method was so much faster...

Share this post


Link to post
Share on other sites

Remember accessing via file sharing will not retain permissions or other metadata; Client access stores the file exactly as it is on the Source volume.

Share this post


Link to post
Share on other sites

Well, I tried a test with my own computer in client mode. It seems really lame that you only define what you don't want to backup, rather than defining what you do want to backup. What happens when you temporarily attach a new drive - does it suddenly start backing that up as well?

Share this post


Link to post
Share on other sites
It seems really lame that you only define what you don't want to backup, rather than defining what you do want to backup.

 

That limitation is only if you are configuring the software backwards; it's designed as a network backup solution that's setup at the server end and pulls the data in. That gives you complete and granular control over the Sources you want to copy.

Share this post


Link to post
Share on other sites

That limitation is only if you are configuring the software backwards; it's designed as a network backup solution that's setup at the server end and pulls the data in. That gives you complete and granular control over the Sources you want to copy.

 

Oh, cool. Thanks!

Share this post


Link to post
Share on other sites

Since the server to be backed up is always on, I assume a "Proactive Backup" would not be necessary, and could just go with normal backup on a schedule? Any thoughts on this?

Share this post


Link to post
Share on other sites

Since the server to be backed up is always on, I assume a "Proactive Backup" would not be necessary, and could just go with normal backup on a schedule? Any thoughts on this?

Proactive backups are most useful when you can't rely on having the client machine online at a specific time. Scheduled backups are most useful when you want a log record of Retrospect's attempt to contact/back up each client. The choice is pretty much up to you.

 

That being said, Retrospect (the company) currently seems to be having trouble getting the engine to communicate properly with specific client versions during the two different types of backups. In many cases Retro 9.0.0 had trouble connecting with 6.x clients in scheduled but not proactive backups, and it's been reported that Retro 9.0.1 can experience a similar difficulty with v9.0 clients. (These failures result in 515 piton protocol errors.) If you happen to experience one of these issues, it could obviously affect what type of backup you choose to perform.

Share this post


Link to post
Share on other sites

Can I even install the client on a server, or do I need a "multi-server" license to backup one server to another?

If both the Retro backup computer and the client are running OS X Server, you will either need to spring for the multi-server license or purchase an additional client server license. If only one is running OS X Server, single-server will be sufficient. If nether is running OS X Server and you currently are running Retro 9 Desktop, you shouldn't have to upgrade.

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
Sign in to follow this  

×