Newbie Advice

[snorkel]

Hello,

 

I'm in the process of evaluating Retrospect with the hope of replacing our current backup software, NetVault, with it. So far it seems to work really well with our library and is backing up like a champ. My problem is that I'm having a hard time figuring out how to setup my backup jobs to take place the way we want them. Can someone offer some advice, please?

 

What we do in NetVault is a full backup every Friday and incrementals Monday through Thursday. Our media retention rule is to discard the incrementals each week, but to save the last four full backups. I understand that I can do a recycle and then normal backup jobs for my full and incrementals, but I don't see how to tell Retrospect to retain media for old jobs. For that matter, I don't see where I can tell Retrospect to re-use tapes. I know there is grooming for disk based backups, but what about tapes?

 

Also, a question about backup set strategy. Our library has 48 slots and two drives. In NetVault we would put the large bulk of our media in one backup set and tell NetVault to use whatever tape was handy to perform a job. In Retrospect, however, it appears that if all of our media is part of one backup set and two jobs execute that require that backup set they will not run at the same time because the set is in use by the first job even though there are plenty of other tapes available. What I would like is to have all backup jobs go to the same media set except for the offsite backups. Is this possible, or do I need to split my sets to ensure that large backup jobs can run at the same time?

 

I'm definitely willing to be flexible, I just want to make sure I get everything setup correctly the first time. Thanks for any advice you folks can offer!

[MRIS]

Hi Snorkel,

 

To simulate the idea of having a tape with a Full backup on it, and another tape with Incremental backups on it, you would drive retrospect like this:

 

1. On Friday do a Normal Backup to a Backup set with 1 blank tape in it. (this is your full).

 

2. On the very next day Normal Backup to the same Backup set, but with the "new media" option. (this forces retrospect to ask for a second tape, which in effect becomes your incrementals tape.)

 

3. For all subsequent days in the week, Normal Backup to the same backup set, but this time without the "new media" option. (this makes retrospect write the rest of the incrementals for the week to the incrementals tape.)

 

4. The following Friday repeat steps 1-3 but using a different Backup set with 1 new blank tape in it.

 

Since it is very unusual to only want to keep the full and discard all the incrementals, the technique to use in retrospect would be to edit the backup set and simply indicate to the software that all tapes but the first tape has gone missing.

 

 

To ensure both drives are used concurrently, you would define more than one backup set, since only 1 backup set can be written to at a time.

 

If you have the proactive backup option, simply specifying both backup sets as options for the backup, whichever is available (ie not in use) will be used at the time the proactive system determines that a backup is due. However this does result in both backup sets filling with the same client's data effectively twice.

 

This means you may need to group your sources into 2 sets, have two backup sets, so that each drive gets used.

 

How many sources do you have?

Are they PCs or Servers or both?

Have you considered a D2D2T strategy?

Have you read the D2D2T witepapers?

[snorkel]

Hi MRIS. Thanks for your reply.

 

Perhaps what I should ask is for advice on backup strategies. I was surprised to read that keeping fulls and discarding incrementals is unusual. I thought this was a pretty standard way of handling backups. My experience is that when a file is in need of being recovered it is either discovered right away or not for several weeks/months. So we want incrementals during the week so our backups are no more than one day behind, but at the end of that week we do a full and keep that for at least four weeks. Then at the end of the month we transfer the last full backup to a new tape and take it offsite for at least a year.

 

Maybe my problem is ultimately related to how tapes are re-used in Retrospect. In NetVault I can set rules saying that a full backup cannot be overwritten until 4 more have been created and that incrementals can be overwritten when one has been created. However, NetVault will not actually overwrite a tape until it has no other tapes available. So while I can tell it to overwrite an incremental immediately, it won't actually do so unless it is necessary to accommodate a new backup job. The result is that I typically end up with tapes in my library that have data from several months ago, but I don't need to actively watch my media usage to make sure I don't run out. I've watched the Retrospect training videos and have been going through the manual, but I am still unclear as to how Retrospect actually retires a backup job aside from doing a recycle backup or manually erasing a tape. Is there any built in intelligence in the software that will reuse an old tape? How do you set that up?

 

As for D2D2T backups go, yes, that is ultimately what we'll want to do. We are currently just evaluating Retrospect and it is sitting on a small workstation with little disk space. I do have some jobs utilizing this backup strategy, but our two big jobs (Exchange and our main file server which comes out to a little over 2TB) need to go directly to tape.

 

I currently have 14 sources that are all servers, and I have 3 desktops setup for proactive backups. If we decide to move forward with Retrospect the server count should stay the same (and eventually go down) but the Proactive desktops will increase considerably... As will the hardware that we dedicate to the Proactive server.

[jerrytopology]

Hello Snorkel,

 

I think what you are attempting to do is similar to what I had to do for a client a while back.

 

The best way (IMO) is to create 4 backup sets for the Weekly backups: Week1, Week2, Week3, Week4. Schedule them as Recycle backups on a Repeating Interval every 4 weeks, with one starting this week, one next, and so on.

 

Then set up a daily backup set which will run each day recycling on Monday (or whatever day you decide on for the break).

 

These are all independant sets, which then prevents on being overwritten in the wrong week etc.

 

I hope that is clear, please do ask me for clarification if not!

 

Jerry

 

[snorkel]

JerryPringle,

 

That makes quite a bit of sense, thank you. The only problem I have is that I think I set something like this up originally but my problem was that it did not appear like my normal backup set had any knowledge of my full backup set(s). In otherwords, I ran a full backup (recycle) over the weekend and to one backup set and then on Monday I ran a normal backup to a different backup set, but instead of just backing up the changes from Friday to Monday it ended up doing another full. I'll have to play with it again.. I probably setup my backup sets incorrectly.

 

Thanks for the advice!

[MRIS]

The Normal (Recycle=Full) and Normal (Normal=Differential) backups must be done to the same backup set. If you try to use different backup sets then the first time a set is used it will always be a full.

 

This is because Retrospect does NOT use the archive flag on files like lesser backup systems do. Rather Retrospect maintains a database (backup set catalog) of files it has backed up previously. Thus if the database is empty (eg as another empty backup set would be) it knows it has to backup all the files.

[snorkel]

That is disappointing. For some of our backups a full backup can take well over 24 hours. Performing a full backup on Friday and then another one on Monday is just not feasible. Seems strange to me that you can't link the backup jobs together in Retrospect.

 

I guess the best bet would be to do four different backup sets with each set lasting an entire week.

 

With that said, my company has decided to make the move to Retrospect and we are purchasing a new backup server with a considerable amount of disk space, so at least we'll be able to go the D2D2T route.

[Lennart_T]

That is disappointing.

Quite the contrary. If Retrospect DID rely on the backup bit, you couldn't have more than one full backup.

Now you can have multiple backup sets with all your files stored at different sites.

[Mayoff]

Retrospect uses the archive bit to track NTFS permission changes on files. You need to have be copying file permission for this to be the case.

[MRIS]

There's an optional feature named "Advanced Tape Support" that allows two tape drives to be written to concurrently by the same backup/set.

See page 13 of the PDF manual.

[snorkel]

Quite the contrary. If Retrospect DID rely on the backup bit, you couldn't have more than one full backup.

 

I don't see why not..? You want another full backup stored elsewhere, then run a full backup and store it elsewhere..? I don't understand how giving normal backup jobs the ability to realize that a full backup exists for the data set would take away that ability.

 

I must just be misunderstanding the point of a "Normal" backup.. My understanding is that a Normal backup should backup everything that has changed since the last "Recycle" backup. I'm just saying that it would make a lot of sense if you could tell your Normal backup executions that your last Recycle backup just might be on a different backup set. Now I'm stuck with keeping my incrementals on the same backup set as my fulls, otherwise I will end up doing two full backups in a row.

[snorkel]

There's an optional feature named "Advanced Tape Support" that allows two tape drives to be written to concurrently by the same backup/set.

 

How do you set this up? I have the Advanced Tape Support running, but if I try to run two jobs using the same backup set one of the jobs sits idle saying that it is waiting for media, and it will not run until the first job finishes. If I have two jobs using different backup sets then they will run at the same time.

[Lennart_T]

Quite the contrary. If Retrospect DID rely on the backup bit, you couldn't have more than one full backup.

 

I don't see why not..?

Because the first backup would set the bit as "backed up" and the next backup would read the bit and not back up all those files.

 

There is just one bit per file, so each backup set must keep its own record of the files it contains.

 

I must just be misunderstanding the point of a "Normal" backup.. My understanding is that a Normal backup should backup everything that has changed since the last "Recycle" backup.

 

You should add just a few words to the last sentence:

My understanding is that a Normal backup should backup everything that has changed since the last "Recycle" backup of the same backup set.

 

I'm just saying that it would make a lot of sense if you could tell your Normal backup executions that your last Recycle backup just might be on a different backup set.

 

I don't see the logic at all. How would you keep track of which "recycle" backup set your "Normal" backup set relies on? If (I mean WHEN) you need to restore you need both and you need the right ones.

[MRIS]

How do you set this up? I have the Advanced Tape Support running, but if I try to run two jobs using the same backup set one of the jobs sits idle saying that it is waiting for media, and it will not run until the first job finishes. If I have two jobs using different backup sets then they will run at the same time.

 

Sorry, I was mistaken about the same backup set to two drives statement. Please refer to pages 163 and 164 in the PDF manual for details with examples. You are still limited to 1 backup set per drive, but the advanced tape support option allows retrospect to use multiple drives concurrently albeit with different sources (servers) and targets (backup sets).

[snorkel]

I don't see the logic at all. How would you keep track of which "recycle" backup set your "Normal" backup set relies on? If (I mean WHEN) you need to restore you need both and you need the right ones.

 

I see what you are saying. What I'm thinking about is the way that NetVault handles this. It has an option when setting up an incremental job to backup all the files that have changed since the last full backup of the data set. NetVault doesn't use the NTFS archive bit at all, and instead it keeps track of file changes on it's own by comparing checksums of the files at time of backup. So you simply setup a set of files you wish to backup and then you schedule jobs to backup that file set to whatever media you choose. It keeps track of when a full backup is done against that set and then uses that backup to determine file changes for incrementals. Doesn't matter what media set you throw the backups at.

 

Pros and cons to every solution, I suppose. We'll just need to re-think our backup methods to deal with this limitation.