Hi Pratik

This is probably achievable within NetWorker, but I reckon it will take a lot to set it up and administer, especially the pools.

When you say "customer", do you mean a third party company that, essentially, pays your wages or an internal customer to your business?  Do they realise that they will use a lot of tapes by narrowing down Monday's backups to Monday tapes and so on as tapes will be exported while still having some space left on them?  What happens if a backup starts on Monday and runs until Tuesday - what pool should it be written to?

Is there a reason that they use Monday tapes, Tuesday tapes and so on or do they mean "all tapes written to on a Monday night/Tuesday morning should be exported and sent offsite on a Tuesday"?  If that is the case, then the pools will be fairly straight forward.

Regarding the schedules, if all clients conform to those schedules, this should be fairly straight forward to set-up, too.  There is no correct way to set-up the clients/groups (everyone on here has their own way of working), but one way is to have three schedules, three groups (with the pool and schedule set against the group) and one client spread to all three groups - the retention would be set against the pool.

Of course, this assumes that the same data (i.e. saveset of All) will be backed up at each of the three retentions/schedules, that backups won't over-run, that pool selection is basic (i.e. Daily, Weekly, Monthly) and so on.  It also won't guard against a monthly full backup over-running and the daily backup starting when it is due.

I think you really need to verify what the customer is looking for and see if you can persuade them to agree to a less restrictive tape regime.

Brian

Hi Brian,

Yes, by the term "customer", i mean that this is an internal customer to our business.

I realize that they will be using lot of tapes but again it is their requirement since it a financial firm and they will be procuring tapes for the same. Also, backups will be starting from 01:00 AM in the morning and so there are very less chances that a backup might run over the next day.

Also, backups written on tapes Monday early morning will be sent the same day offsite once all the backups complete. This tape will then be brought onsite next monday only for backup.

If this is the case, we will be creating only one pool for daily backup and all the tapes will be having same Label...right ?

So, the client configuration would be somewhat like this:

Group A: Client A , Client B, Client C and so on with pool "Daily Backup" , schedule "Weekly Full Daily Incremental" & Retention "One week"

Group B: Client A , Client B, Client C and so on with pool "Weekly Backup" , schedule "Weekly Full Daily Incremental" & Retention "One month"

Group C: Client A , Client B, Client C and so on with pool "Monthly Backup" , schedule "Monthly on 1st of every month" & Retention "7 years"

What should be done when the daily & monthly backups come on same day.

Please suggest.

Pratik.

Hi Pratik

Yes, that client/group/pool/schedule configuration would certainly work.

Although not foolproof, you could use the skip part of a schedule to try to avoid clashes.  Set the schedules up as normal.

"Weekly Full Daily Incremental" would be Full (Sunday), level 9 (or whatever) the rest of the week:

Then, use nsradmin to skip the backup on the first day of the month:

nsradmin> print type: nsr schedule;name:Test

                        type: NSR schedule;

                        name: Test;

                    comment: ;

                      period: Week;

                      action: full 9 9 9 9 9 9;

                    override: ;

nsradmin> update override: "Skip first day every month"

                    override: Skip first day every month;

Update? y

updated resource id 160.1.92.16.0.0.0.0.123.230.120.81.0.0.0.0.10.10.254.7(2)

nsradmin> print type: nsr schedule;name:Test

                        type: NSR schedule;

                        name: Test;

                    comment: ;

                      period: Week;

                      action: full 9 9 9 9 9 9;

                    override: Skip first day every month;

nsradmin>

Now if we look at our schedule, you will see that there is an ever-lasting skip on the first day every month:

You would set up your "Monthly on 1st of every month" schedule in a similar way:

nsradmin> print type: nsr schedule;name:Test_Full

                        type: NSR schedule;

                        name: Test_Full;

                     comment: ;

                      period: Week;

                      action: skip skip skip skip skip skip skip;

                    override: ;

nsradmin> update override: "Full first day every month"

                    override: Full first day every month;

Update? y

updated resource id 163.1.92.16.0.0.0.0.123.230.120.81.0.0.0.0.10.10.254.7(2)

nsradmin> print type: nsr schedule;name:Test_Full

                        type: NSR schedule;

                        name: Test_Full;

                     comment: ;

                      period: Week;

                      action: skip skip skip skip skip skip skip;

                    override: Full first day every month;

nsradmin>

The beauty about the "Skip first day every month" syntax (and the others - look at the man pages) is that it is perpetual, i.e. you don't need to manually set the skip for the next so many months and then remember to do it again - simply set it up once and never touch it again!

AsI said, though, this will not guarantee that the monthly full and the daily/weekly backup will not clash; it depends on how long the backups run for.

As all of the tapes written that day will be exported, I would also recommend that you mark each tape as being full so that when they are put into the library next week, they will only be written to if they are recyclable, i.e. you do not have last Monday's data co-existing with this Monday's data:

nsrmm -y -o full {Tape}

This should be able to be easily scripted as part of your export list/jobs, whatever you use to determine what tapes are coming out the library.

I hope this helps!

Brian

Hi Brian,

That was too good of a solution. It has solved my major problem of my Manual intervention.

We have created the schedule as specified above and will soon be starting the backups.

Thanks for your valuable suggestion.

Pratik.

You're very welcome, Pratik.