Proactive Scripts Not Really Working

[6bb4e311-4536-4d71-81d2-1910303931c9]

I've setup many proactive scripts, but for some reason, they only work so and so. One of the nags goes this way:

 

- Created a new user on a machine, changed the machine's net name

- defined a script as proactive

- set the client to allow backup as soon as possible

- checked that the client really is accessible and defined the user folder to be a source for the backup

 

The proactive backup script is set to check sources every minute, client connect every two minutes, retry failure every 5 minutes.

 

Then, I waited for several hours for the script to kick in and get that new data, that was available. Remember, the userfolder

was created freshly so all was new.

 

The bloody script never kicked in.

 

Any ideas on why the above steps won't make Retrospect to start getting the new data almost INSTANTLY?

 

cheers

®

[Lennart_T]

I'm not familiar with Proactive backups on Mac, but on Windows there is a status window for all proactive clients. There is a status column, where the status for each client is displayed. For instance "busy" means the media set is already in use by another operation, "source" means the client is off line. What is Retrospect telling you on your server?

[6bb4e311-4536-4d71-81d2-1910303931c9]

Thanks, Lennard.

 

The client just sat there idle for hours, the script didn't report anything like mediaset in use or something. It simply didn't do

anything. The next day it did backup the client, but I simply don't get the concept behind proactive scripts.

 

If the client is available, has new data and has the client software set to allow backup as soon as possible and

the server is idle and the mediaset therefor is idle too. why wouldn't Retrospect simply check the client after the

value defined in script>options > Proactive Backup.

 

In the script, the checkbox "allow early backup" is checked. Source should be checked within a minute.

 

It seem to be eratic, when exactly Retrospect server starts to backup under the above conditions.

 

cheers

®

[f30e6e60-a263-4d69-8f60-c92703669308]

Of the nags listed, does the same thing happen if you _don't_ change the machine's "net name" (which is what, the Sharing/Bonjour name, or the DNS hostname?)

[abb668b8-e67d-45d2-8fe4-b2a87dc2831e]

Proactive backups only work when the user is logged in.

Proactive backups currently don't work for a user who is on the same machine as the Retrospect Server is installed on.

[6bb4e311-4536-4d71-81d2-1910303931c9]

Thanks, CallMeDave and backup zen.

 

For the name changing: I did remove the source form the backup and loaded it freshly. That didn't respect the sharing name. I had to kill the local retrospect daemon and throw away the preferences. Then, the server learned the new name.

 

 

And I did let the computer sit idle with the user logged in - so I was able to see the status in the retrospect client window. The client was waiting for the first contact for hours, even when the server was sitting idle and the proactive script didn't perform a first backup for the waiting client. So it simply didn't do anything useful.

 

The longer I read the feedback, the more I am convinced that retrospect v6 was a working solution for my environment and v8 simply isn't. I also seldom see any reaction from a roxio support person here. I understand they provide the forum and leave the problem solving to paying customers? :-/

 

Thanks much for your input, guys.

 

cheers

®

[abb668b8-e67d-45d2-8fe4-b2a87dc2831e]

Are you running 6.3.029 client version?

 

I have a proactive script set up on a filevault user. It's very good about backing up when I log in.

[6bb4e311-4536-4d71-81d2-1910303931c9]

Yep. 6.3.029. I suspect, it has to do with me having 40+ Proactive scripts...

[f30e6e60-a263-4d69-8f60-c92703669308]

I simply don't get the concept behind proactive scripts

 

This could be the problem, of course. We still don't know the specifics of your configuration (hardware or software), so it would be irresponsible to preclude good ol' user error for all for all of this.

 

- defined a script as proactive

 

A Proactive Script has five option tabs (plus the Summary). We still only have a partial description of your settings.

 

The next day it did backup the client

 

What is set in the "Schedule" tab?

[Guest Steve Maser]

Yep. 6.3.029. I suspect, it has to do with me having 40+ Proactive scripts...

 

 

Oh, yeah -- that won't work well.

 

I tried that once -- giving each client it's own media set/proactive script.

 

I tried running that for about 10 minutes, and then realized nothing was actually working. Maybe if you have 32G of RAM on the backup server it might, but with 4G of RAM, it brought the engine computer to it's knees.

[6bb4e311-4536-4d71-81d2-1910303931c9]

This could be the problem, of course. We still don't know the specifics of your configuration (hardware or software), so it would be irresponsible to preclude good ol' user error for all for all of this.

A Proactive Script has five option tabs (plus the Summary). We still only have a partial description of your settings.

What is set in the "Schedule" tab?

 

Oh, I posted that info in the generic feedback section and didn't include it here, sorry. So, here's the challenge and setup:

 

RS Backupserver-Hardware:

 

- one Mac Server (2*2.66 GHz QuadCore, 8 GB RAM, Gigabit Ethernet)

- Three firewire drives

- Internal SATA drive for the backup catalogs

 

- 8 servers to backup, every two hours

- 40 desktop clients to backup every four hours

- 8 Laptops to backup as soon as they connect, then every four hours as long as they are connected

 

One of the 8 servers is a AFP Server with 35 sharepoints, each one being backed up every two hour

 

So, I setup three mediasets:

 

- one for the server backups

- one for the user-backups

- one for a copy of the backups to move them offsite every now and then (approx. every 2 month)

 

Every user, server and sharpoint has it's own backup script.

 

The summary and the source tab won't tell you much, will they? The source has been added and a Userfolder defined. Usually

only one folder on each source is included in the source definition of the script.

 

One MediaSet of Type Disk is defined (and has 300GB+ free space). This is the same mediaset for all Users. There is one more mediaset for all servers.

 

Rules: all files except cache

 

Schedule: all 4 hours 24h a day all weekdays

 

Options:

Proactive Backup: Allow early backup checked, countdown time 0, Source checked all 60 Seconds, Client check all 120 seconds, Retry after failure all 2 Minutes.

No verification, compression in software checked

Compare with medisaset checked, add no duplicates checked, last option not checked

Source: don't sync clock, no thresholds defined

 

 

cheers

®

[6bb4e311-4536-4d71-81d2-1910303931c9]

Oh, yeah -- that won't work well.

 

I tried that once -- giving each client it's own media set/proactive script.

 

I tried running that for about 10 minutes, and then realized nothing was actually working. Maybe if you have 32G of RAM on the backup server it might, but with 4G of RAM, it brought the engine computer to it's knees.

 

Well, it worked quite nicely with Retrospect 6.2. We had the same setup and RS simply cycled through the list of backup scripts, checked if a client is available, if it is, RS checked if new data is available and performed a backup. That was with the dame amount of clients and a older, less capable server.

 

This is why we are surprised. In v8 this simply won't work reliably so it's a step backwards - or we didn't understand properly what exactly has changed in the basic logic of RS.

 

cheers

®

[Guest Steve Maser]

Retrospect 6.2 didn't have the concept of "Proactive" scripts -- it's not the same as a "Backup Server" script in 6.2

 

 

Proactive scripts can be set to run concurrently -- "Backup Server" -- would only backup one instance of something at one time. It would *walk through the list of clients* regularly -- but it still would only backup one thing at a time.

 

 

So if you set up 56 (!) individual Proactive Scripts -- you are going to overwhelm the engine. It *may* work, but you'll find yourself unable to get any information from the console at any given point (my experience...)

 

 

What you probably want (it sounds like) are just *two* proactive scripts -- one for your servers that points to your "server" media set -- and contains all your servers as sources -- and one for your clients that points to your client media set and contains all your *clients* as sources.

 

 

Because you are looking to do backup every 2/4 hours, I might suggest you make a few more media sets and stagger your server/client backups between them (if, for example, you can't walk through all 8 servers in two hours -- you might need 2-3 "server" media sets) -- that way you *can* make more proactive scripts, but not design one for each machine.

 

I found that on a machine with 4G RAM (only doing a backup every 24 hours), if I have more than 8 proactive scripts, then it starts to bog down -- regardless of how many clients exist per script -- especially if multiple backups are running. You have 8G of RAM, so you could probably run more than 8 concurrently, but I wouldn't recommend setting it up that way until you test it to see how responsive the console is when the scripts are running.

[6bb4e311-4536-4d71-81d2-1910303931c9]

Thank you, Steve. Most appreciated.

 

Well, since the cycling through scripts in RS 6.x was doing so fine and checked the sources one by one in sequence and all day long, that would be what I wanted to see in 8.2 too.

I didn't feel like having all sources in one script will make restoring files easy but reading your message, I feel, we need to reconsider the whole setup we have in retrospect.

 

If I have e.g. 10 sources in one proactive script, does the script detect, whenever a source becomes active on the network (e.g. the user arrives at work and logs in)? If yes, does it

then starts to make backups - of ALL sources in that script?

 

Meaning, if the last source in the backupscript becomes active, does the script start again making backups of all sources in that script?

 

cheers

®

[Lennart_T]

Here's how it works on Windows, and I pretty sure it's the same way in Retrospect 8.2 on Mac.

 

A list of clients is maintained. At the top there are the client that most urgently needs backup (as a long time has elapsed since the last backup). Retrospect tries each client from top to bottom. Once an "online" client has been found (and the media set isn't in use) the backup starts for that client. Retrospect continues down the list to find another client to backup to another media set. Once a client has been backed up, it is moved to the bottom of the list, which means the lowest priority.

 

In my case I have three media sets, so three backups can (and do) occur simultaneously.

 

 

 

As you can see, some of the clients are "Busy" as they belong to the same media set as the one being backed up.

Others are "Source", meaning "Source not available".

One is "Executing".

One is "Retry", since the backup being interrupted by the client going offline in the middle of the backup.

[Guest Steve Maser]

Thank you, Steve. Most appreciated.

 

Well, since the cycling through scripts in RS 6.x was doing so fine and checked the sources one by one in sequence and all day long, that would be what I wanted to see in 8.2 too.

I didn't feel like having all sources in one script will make restoring files easy but reading your message, I feel, we need to reconsider the whole setup we have in retrospect.

 

If I have e.g. 10 sources in one proactive script, does the script detect, whenever a source becomes active on the network (e.g. the user arrives at work and logs in)? If yes, does it

then starts to make backups - of ALL sources in that script?

 

Meaning, if the last source in the backupscript becomes active, does the script start again making backups of all sources in that script?

 

cheers

®

 

 

 

Yes -- Proactive Scripts are almost like Backup Server scripts in the sense that they will continue to cycle through the list of sources and see if they need to be backed up -- ie, the "laptop just showed on the network, so back it up now" works like you expect. And it still works in the way that the backup is controlled by the last backup date (as you want) -- ie, if you have 10 sources in the script and you want them to backup every 4 hours, it will back up the visible sources every four hours based on their last backup time. It doesn't "restart the script" like a *Backup* script does. Proactive is constantly polling things and comparing the client backup time to the script requirements. That "constant polling" is what can cause problems (as you've seen...)

 

Where Proactive *doesn't* work like Backup Server is there's no direct way to mark a machine as to backup "ASAP" from the Engine. There are ways to trick this, but it's not obvious. That's been a constant feature request from me since the beginning.

 

Where backup server just checked one machine at a time before moving to the next one, Proactive Scripts appears to check everything all the time, so the fewer proactive scripts you have, the less time spent "checking" everything (which is where the one-script-per-client method bogs down the engine...)

 

 

What Proactive scripting *adds* (that Backup Server could *not* do) -- is "concurrent backups". If you have 3 Proactive scripts, they can be backing up clients to different media sets *at the same time*.

 

 

So, how I designed my scripts was to put a mix of desktop *and* laptop clients into each script (I have 6 non-server proactive scripts that backup clients) -- that way it spreads out the "a laptop just showed up on the network" backups a bit more. Frequently (like between 9-11 a.m.), I will have 4-6 concurrent backups running backing up laptops that just showed up on the network.

 

 

It's a trial-and-error method of right-sizing this. My system will frequently put the Console into SPOD mode if I leave it open because the console won't respond if there are 5-6 active backup activities processing. I have some colleagues who just dump all their clients into 1-2 scripts and that works for them to backup everything from (primarily) 9-5. My goal was to try to get everybody backed up daily between 8-1 so if I needed to work on something with the engine, I could (usually) be assured that there would be no backups running in the late afternoon. However, the Console SPOD has occasionally limited the ability to do a restore of something without having to "Pause All" and then stop active backups. Fewer scripts would make that better, but I decided to go with "get them all done fast" over "give the console more threads".

 

YMMV to figure out what works best for you. You have a stated goal of "every 4 hours" of backup. To me, that seems like a lot of backup, but your retention policy differs from mine (one-a-day works for me...)

Edited April 14, 2011 by Steve Maser

[f30e6e60-a263-4d69-8f60-c92703669308]

I didn't feel like having all sources in one script will make restoring files easy

Completely unrelated. You can have one script for your Media Set or a thousand; the Media Set will still contain the Backups, the Restores will still work the same way.