Volume Backup Date not set

[syscom]

We recently moved from Mac OS 10.3.9 to 10.5.4.

In a rotating 4-week scheme we do a recycling full backup in the weekend. Every Mon, Tue, Wed, Thu, we then backup files changed from the weekly backup.

The new problem is, that Retrospect does not fill or change the field "Backup Date" on the Volume. (Configure > Volumes > Get Info)

So after the weekly full backup, it will try to backup all files again on Monday.

Using: Restrospect Workgroup 6.1.203 and driver 6.1.15.101

[Mayoff]

Retrospect has never used a volume backup data to identify changed files. If it is trying to copy all files again, then something is wrong with the backup set, or something is making all the files appear to have changed.

[syscom]

On MacOS 10.2. and 10.3 I have already 4 years used for selecting files:

Include files matching "modify time ≥ volume backup"

But since the reinstall on OS 10.5 it fails.

And searching for the cause I found the the empty field in volume info: Backup:

Remember this is the default in Options for backup: Source: Set source volumes' backup time.

I have only checked this option, not the source folders or the source file.

It seams to be broken.

[CallMeDave]

Retrospect has never used a volume backup data to identify changed files

 

While this is of course true, the "Backup:" field in Configure->Volumes->FooVolume->Get Info does show the time/date of the most current Retrospect backup. I just tried on OS X 10.5.4 and the Backup: field was correctly populated with the date/time of my test backup.

 

Include files matching "modify time ≥ volume backup"

 

I've never used this selector, (although you're being imprecise in your wording, as there is no "modify time" choice, only "modification date" and "modification date and time." Words matter a great deal when describing issues online) so I'm not sure what value it brings to your selection process.

 

Retrospect works without the need for this selector; files that have been modified since the last time they were added to the Backup Set in use will be copied again. I'd say loose the overly-complex configuration and try to use the unique features of the program as intended.

 

Dave

[syscom]

Thank you both for spending time and looking into this.

I just tried on OS X 10.5.4 and the Backup: field was correctly populated with the date/time of my test backup.

Intriguing... I have seen the empty field on the xserve G5 and on an Intel QuadCore Duo, both on fresh installed Mac OS 10.5.4 and freshly formatted disks. On the latter, if you use a Retrospect browser on the volume, it shows the backup date and time; but in Retrospect directory > Configure > Volumes > Get Info there is nothing behind Backup:

Maybe Time Machine is acting on the same fields. I have tested this program also on both machines. But that was a short exercise before I used Retrospect again.

 

(although you're being imprecise in your wording, as there is no "modify time" choice, only "modification date" and "modification date and time." Words matter a great deal when describing issues online) so I'm not sure what value it brings to your selection process.

In the window where you assemble the selection you see the composition of: "File" "modification date and time" "is" "on or after" "volume backup" "no offset" but in the summary listing the phrase is: "modify time ≥ volume backup". Sorry that I copied it from there.

 

Retrospect works without the need for this selector; files that have been modified since the last time they were added to the Backup Set in use will be copied again. I'd say loose the overly-complex configuration and try to use the unique features of the program as intended.

We could have nice discussions about backup strategy and -schemes. But many years ago we have set up the following:

We use a dds4 tape drive. It does not allow to add data behind existing recorded data on a tape.

A rotating recycling scheme of 4 weeks: Every week a complete backup. (tapes: week1 ,week2, week3, week4) (set b/u time) rotated recycling.

Every day the modified from last week backup. (Tapes: Mon, Tue, Wed, Thu,) (don't set b/u time) These are all kept in a data safe.

Every 4 weeks a complete backup taken off site. (Tapes: per1, per2, per3, per4)(don't set b/u time) rotated recycling.

So the complete number of tape sets is 8 plus the 4 daily. We use a nice Excel calendar.

You may consider it as complex, but it has worked nicely for many years. And it is easy to do. Older files are kept for reasonable time.

 

Of course we could trash this and try to find an equally safe or better scheme with available selection possibilities. But we wonder why the move to 10.5 obviously has broken the program.

Further I don't see that our approach is a contradiction to how the program is intended.

[CallMeDave]

many years ago we have set up the following:

 

As your specific use of Backup Sets and tape members was not previously described, I would not have been able to comment on its complexity. My use of the term "overly-complex configuration" was in regards to your using a Selector to get Retrospect to backup files that had changed since the last time Retrospect had backed them up. Retrospect requires no selector to behave that way; in fact, Retrospect's ability to Match the state of current files against those files' attributes at the last backup is one of the program's strong parts.

 

While I'm not in a position to have deep understanding of your backup strategy, it sounds as if you could just delete this Selector and move on.

 

we wonder why the move to 10.5 obviously has broken the program

.

 

Not obvious to me; program behaves as I expect it to on my un-clean test system.

 

To be clear, the test Volume I used as my Source was /usr/bin/ that had been defined as a Subvolume. I do not know if using the root of a volume would have yielded the same results.

[syscom]

Off course there are ways out. But in the first place it should function.

And I want to draw the attention of [color:blue]EMC Insignia[/color] to point them to a what looks like to be a [color:red]defect[/color] or a problem.

 

If I don't like buying 12 new tapes to perform incremental backups to the weekly backups, I need to make the daily backup of changed files independent from a "Weekx" catalog like they are now. The new "DailyUpdates" should compare the backup stamp on every file then.

 

it sounds as if you could just delete this Selector and move on.

I think, that just deleting the selector does not work. The program needs some selector anyway.

 

So what would it be?

Suppose you would suggest: File - modification date and time - is - on or after - file backup - no offset.

 

Then I need to stamp every file. So instead of Options default: set source volumes' backup time, I need to check set source files' backup time (mind write protected!)

Then I create a new backup set called "DailyUpdates" with four members and just backup modified files.

 

Thanks again for you effort.

[Lennart_T]

I need to make the daily backup of changed files independent from a "Weekx" catalog like they are now.

That is exactly the way Retrospect works. When running the daily backup to one of the daily backup sets runs, any single file is backed up only if it has been changed (or added) since THAT backup set was last used. And it's completely independent to any other backup set, such as the "Weekx" backup sets.

[syscom]

When running the daily backup to one of the daily backup sets runs, any single file is backed up only if it has been changed (or added) since THAT backup set was last used.

And it's completely independent to any other backup set, such as the "Weekx" backup sets.

I can only use Retrospect the way is works. Unfortunately it partly stopped working.

 

The trick to do an incremental backup without the use of the "Weekx" catalog is to rely on the backup date/time stamps of the source. Because the volume stamp is broken I need to use the folder stamp or the file stamp.

[CallMeDave]

The trick to do an incremental backup without the use of the "Weekx" catalog is to rely on the backup date/time stamps of the source

 

I am not clear exactly (exactly) what "Weekx" means to you in this context. But out of the box, Retrospect can maintain multiple, independent, incremental Backup Sets without the use of any selector or date/time stamps. No tricks necessary.

 

You're trying too hard; the program works without stamps.

 

 

Dave

[syscom]

out of the box, Retrospect can maintain multiple, independent, incremental Backup Sets without the use of any selector or date/time stamps. No tricks necessary.

 

You're trying too hard; the program works without stamps.

 

Dave

 

Thank you all for your patience.

I have decided to review my policy.

I have bought some extra tapes.

I will keep the four week cycle.

I will just start a recycle backup every week, followed by normal (incremental) backups the following days on the same set.

 

Leaving the defect alone.

 

Thanks again.