Jump to content

List of files restored


kaikow

Recommended Posts

Hi

 

Unfortunately there is no list of files created when you do a restore. Your best bet is to take a look at the files chosen window before you start the restore.

 

Not great but thats the breaks I guess.

 

you could play around with the advanced logging features by typing CTRL ALT P P but I'm not sure it will give you the info you are looking for

 

Nate

Link to comment
Share on other sites

Files chosen doesn't help.

 

 

 

Twice, I've asked Retrospect to restore an entire volume.

 

In one case, as I recall, only 22 files were deemed necessary to restore.

 

In the other case, about 88 files.

 

 

 

A similar case arises if asking to restore selected nodes on the file directoey tree.

 

 

 

There should be a log of files restored.

 

 

 

And Dantz should be responding to this thread, not lea=ving us hanging with an unanswere question.

Link to comment
Share on other sites

Quote:

natew said:

Hi Howard

 

Dantz is responding to this question
wink.gif

 

Unfortunately the list feature doesn't exist. I will pass it on as a feature request. What information are you looking for in this particular case? It sounds like you want Retrospect to restore more files?

 

Nate

 


 

All individuals responding on behalf of Dantz need to be identified in their signature or "title".

 

I was not lookung for more files to be restored.

I was looking or a list of the files that had been restored.

 

If I ask for an entire volume to be restored, or for a subtree of the files to be restored, I would expect one of the following:

 

1. All of the files in the volume or sub tree would be restored.

2. If Retrospect finds that, in its humble opinion, only certain files "need" to be restored, then a log/list of those files needs to be made available.

 

As far as I know, Retrospect does not use all the necessary attributes of a file to determine which are to be backed up or restored.

 

For example, suppose I have a bunch of files for which I am, for whatever reason, causing the read-only and archive attributes to change in various ways.

 

It is my understanding that, at least for the read-only attribute, Retrospect does not consider a file to have been changed if the read-only attribute is different than that of an allegedly identical backed up copy of the file.

 

Applications often need to base decisions on how to proceed based on particular attributes.

So if I have a bunch of files for which I need to change say, the read-only attribute, then I have a right to expect that if I were to backup, then restore those files, I would have the latest set of attributes restored. Apparently, Retrospect does not do this.

 

If there is an already backed up copy of the file that Retrospect "believes" differes only in the read-only attribute, then Retrospect does not backup the file. When I next restore the file, I get the unpleasant surprise of changed attributes. As far as I am concerned, that's a bug in Retrospect.

 

As I recall, I mentioned this in another thread within the past few months.

 

I understand why Retrospect wants to use matching criteria to expedite backup, but a file is a collection of information with associated attributes. Typically, the set of attributes associated with a file includes filename, various dates, read-only and archive. If ANY attribute changes, the the backup copy needs to be replaced with a copy with the correct attributes.

 

 

Link to comment
Share on other sites

Retrospect uses several matching criteria to find new or changed files. If one of the criteria has been changed, Retrospect will back up (or restore) the file. On Windows, Retrospect looks at creation date and time, modified date and time, size and name. Read Only and the Archive bit are not considered in the matching process.

 

 

 

Quote:

All individuals responding on behalf of Dantz need to be identified in their signature or "title".

 


 

 

 

Any Moderator or Administrator (as designated by the user name symbol) is an employee of Dantz.

Link to comment
Share on other sites

Quote:

AmyJ said:

Retrospect uses several matching criteria to find new or changed files. If one of the criteria has been changed, Retrospect will back up (or restore) the file. On Windows, Retrospect looks at creation date and time, modified date and time, size and name. Read Only and the Archive bit are not considered in the matching process.

 

Quote:

All individuals responding on behalf of Dantz need to be identified in their signature or "title".

 


 

Any Moderator or Administrator (as designated by the user name symbol) is an employee of Dantz.

 


 

 

A backup is a snapshot of the files at a point in time.

Restoration requires that all attributes be backed up so that the system can be restored to the state at that point in time.

 

Retrospect needs to back up a file if ANY attrubute has changed, otherwise the state cannot be restored.

Link to comment
Share on other sites

Hi Howard

 

I have added "Dantz" to my title. My apologies for the confusion.

 

In regard to the read only attribute specifically: that information is stored in the snapshot. You are correct that the file is not backed up again as the data itself has not changed. However, the change it the attribute is kept and is fully restorable. A "restore entire disk" restore will update the attributes of all files to match what is stored in the snapshot even if very few files are actually restored. If this is not working for you we should investigate it further.

 

What I hear you saying is that you would like to choose which backup criteria Retrospect uses. You would also like a detailed list of exactly which files are being restored and why as well as a list of files that will have attributes updated even though the file itself will not be restored again. This we can pass on as a feature request.

 

One honest question: Can you help me understand why you need the list of restored files? I'm just not sure I see the real benifit yet.

 

For the record, There are actually a lot of cases where user's want Retrospect to rely on fewer attributes than it already does. The more attributes you rely on to indicate a changed file - the greater the likely hood that a file will be backed up again due to a minor change.

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

In regard to the read only attribute specifically: that information is stored in the snapshot. You are correct that the file is not backed up again as the data itself has not changed. However, the change it the attribute is kept and is fully restorable.

 


 

I'd have to test again to see if the read-only attribute is actually saved when the file, and its other attributes, are not changed.

 

Quote:

A "restore entire disk" restore will update the attributes of all files to match what is stored in the snapshot even if very few files are actually restored. If this is not working for you we should investigate it further.

 


 

I've never investigated that case.

 

Dantz needs to have a KB article that describes what attributes are backed up and restored.

 

Quote:

What I hear you saying is that you would like to choose which backup criteria Retrospect uses.

 


 

Nope.

 

A file is a collection of information with a set of associated atrributes.

A backup must have a copy of each file and ALL of the latest set of attributes for the file, so that a computer can be restored to a point in time.

 

Quote:

You would also like a detailed list of exactly which files are being restored and why as well as a list of files that will have attributes updated even though the file itself will not be restored again.

 


 

Nope.

 

I only want a list of the files restored for those cases in which les than 100% of the files selected are restored.

 

For example, if I ask to have an entire volume restored, but only a few files are actually restored, then I need to know which fies were restored.

 

Quote:

One honest question: Can you help me understand why you need the list of restored files? I'm just not sure I see the real benifit yet.

 


 

That's the only way I can tell what was restored.

I addressed this in another posting in this thread.

 

Quote:

For the record, There are actually a lot of cases where user's want Retrospect to rely on fewer attributes than it already does. The more attributes you rely on to indicate a changed file - the greater the likely hood that a file will be backed up again due to a minor change.

 


 

That is not what users want. Users want to eliminate the backing up of info that has already been backed up.

 

This is a two step process:

 

1. Verify whether the bytes of the file have changed. If so, then backup the file contents.

 

2. If the file attrributes have changed, a mechanism is needed to backup those attributes. A crude way is to make another copy of the file in the backup that has the changed attributes. Another way is to save the attributes as if there were a separate version of the file backed up. How this done depends on the structures used by Retrospect.

 

Users want to be able to backup files at a point in time and restore a system to that same point in time. This can be done only by backing up a file's changed attributes even if the file's content has not changed.

 

Users could be given an option to select the matching criteria, but then Dantz sure better explain to them the implications.

 

Without further documentation, and testing, I am not yet convinced that Retrospect saves and restores attributes properly. Perhaps, al lthat is needed is better documentation.

Link to comment
Share on other sites

Hi

 

Can you tell me exactly which attributes you suspect are not being backed up? That way we can resolve your questions.

 

Since Retrospect can do a full system restore to any point in time it is most certainly backing up all of the needed attributes. Accoring to my tests here Retrospect does indeed store attribute changes in the snapshot.

 

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

In regard to the read only attribute specifically: that information is stored in the snapshot. You are correct that the file is not backed up again as the data itself has not changed. However, the change it the attribute is kept and is fully restorable. A "restore entire disk" restore will update the attributes of all files to match what is stored in the snapshot even if very few files are actually restored. If this is not working for you we should investigate it further.

 


 

The above is incorrect. I just performed the following experiment.

 

I have a file that was created on 12 September 2003 and it has the Archive bit set.

Retrospect had already backed up the file.

 

So, I made the file read-only and did not alter the dates or file content or Archive bit.

 

Ran Normal backup using a script that backs up all internal hard drives.

Examining the session contents, there was no record of the file having been again backed up.

 

I then used Find and the file was listed only once.

 

I then Restored the found file.

 

File had the Archive bit set, but the read-only bit was not set, so Retrospect is indeed not updating attributes as stated above.

 

Retrospect does not make a true backup of a file system.

Users need to be forewarned of this.

Saving ALL file attributes is required to be a true backup.

 

I suppose that the same problem would occur with the Hidden attrribute or if I forced the Archive attribute to clear.

 

Link to comment
Share on other sites

Howard

 

Changing the read only attribute on a file will not cause it to be backed up again. Sou your backup will show no files backed up. However the changed will be noted in the snapshot. I have tested this on my system and it does indeed work. Are you using the restore entire disk option for your restore?

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

Howard

 

Changing the read only attribute on a file will not cause it to be backed up again. Sou your backup will show no files backed up. However the changed will be noted in the snapshot. I have tested this on my system and it does indeed work. Are you using the restore entire disk option for your restore?

 

Nate

 


 

I guess that I do not know how to view the attributes in a snapshot.

How do I do that?

 

And, no, I did not use restore entire disk, as I only wanted to restore a single file.

Requiring the use of "restore entire disk" to get empty directories and, as you say, trhe latest attributes is a very user unfriendly design.

 

Oh well, I better get to bed now. I've been up since yesterday afternnoon, in part, to ovecome a bug in the Microsoft WMI.

 

Oh, there's the sandman, better log off and run Retrospect whilst I sleep.

Link to comment
Share on other sites

Quote:

natew said:

Howard

 

Changing the read only attribute on a file will not cause it to be backed up again. Sou your backup will show no files backed up. However the changed will be noted in the snapshot. I have tested this on my system and it does indeed work. Are you using the restore entire disk option for your restore?

 

Nate

 


 

I havetried to restore using both of the following:

 

1. Restoring using selected files.

2. Restoring using replace entire volume.

 

Can you provide a step by step example that I could try to reproduce?

 

I'm (ab)using version 6.5.319 with update 4.2.107.

Link to comment
Share on other sites

Quote:

Howard Kaikow said:

Quote:

natew said:

Howard

 

Changing the read only attribute on a file will not cause it to be backed up again. Sou your backup will show no files backed up. However the changed will be noted in the snapshot. I have tested this on my system and it does indeed work. Are you using the restore entire disk option for your restore?

 

Nate

 


 

I havetried to restore using both of the following:

 

1. Restoring using selected files.

2. Restoring using replace entire volume.

 

Can you provide a step by step example that I could try to reproduce?

 

I'm (ab)using version 6.5.319 with update 4.2.107.

 


 

How's 'bout a step by step example?

Link to comment
Share on other sites

Quote:

Howard Kaikow said:

Quote:

natew said:

Howard

 

Changing the read only attribute on a file will not cause it to be backed up again. Sou your backup will show no files backed up. However the changed will be noted in the snapshot. I have tested this on my system and it does indeed work. Are you using the restore entire disk option for your restore?

 

Nate

 


 

I havetried to restore using both of the following:

 

1. Restoring using selected files.

2. Restoring using replace entire volume.

 

Can you provide a step by step example that I could try to reproduce?

 

I'm (ab)using version 6.5.319 with update 4.2.107.

 


 

It has been 7+ days since I requested a step by step example from Dantz to prove that Retrospect preserves atttributes.

 

When can I expect such an example?

Link to comment
Share on other sites

Please remember that this is not an official means of contacting Dantz Technical Support. It is a community forum for users to help other users. While we heavily moderate this forum, it is not possible to answer every post.

 

From the Forum Welcome letter:

 

---

Forum Moderators

 

Moderators are Dantz Employees who focus on:

 

-Gathering feedback that will be forwarded to the appropriate Dantz Department

-Identifying possible content for Knowledge Base

-When possible, correcting erroneous information in the forums.

 

Moderators will also attempt to maintain proper decorum in the discussion forums.

 

Due to post volume and other factors, Moderators may not respond promptly, or at all, to these discussions.

 

IMPORTANT: Employees of Dantz Development Corporation may respond to issues within this forum. Dantz is under no duty to provide a response to an issue, or to do so in a timely manner.

Link to comment
Share on other sites

Quote:

AmyJ said:

Please remember that this is not an official means of contacting Dantz Technical Support. It is a community forum for users to help other users. While we heavily moderate this forum, it is not possible to answer every post.

 

From the Forum Welcome letter:

 

---

Forum Moderators

 

Moderators are Dantz Employees who focus on:

 

-Gathering feedback that will be forwarded to the appropriate Dantz Department

-Identifying possible content for Knowledge Base

-When possible, correcting erroneous information in the forums.

 

Moderators will also attempt to maintain proper decorum in the discussion forums.

 

Due to post volume and other factors, Moderators may not respond promptly, or at all, to these discussions.

 

IMPORTANT: Employees of Dantz Development Corporation may respond to issues within this forum. Dantz is under no duty to provide a response to an issue, or to do so in a timely manner.

 


 

A DAntz employee asserted, in this firum, that it was possible to restore the correct attributes and stated that he was able to do so.

 

I responded by asking for the steps used.

 

Such a response is appropriate for this forum.

Link to comment
Share on other sites

  • 3 weeks later...

Quote:

Howard Kaikow said:

Quote:

AmyJ said:

Please remember that this is not an official means of contacting Dantz Technical Support. It is a community forum for users to help other users. While we heavily moderate this forum, it is not possible to answer every post.

 

From the Forum Welcome letter:

 

---

Forum Moderators

 

Moderators are Dantz Employees who focus on:

 

-Gathering feedback that will be forwarded to the appropriate Dantz Department

-Identifying possible content for Knowledge Base

-When possible, correcting erroneous information in the forums.

 

Moderators will also attempt to maintain proper decorum in the discussion forums.

 

Due to post volume and other factors, Moderators may not respond promptly, or at all, to these discussions.

 

IMPORTANT: Employees of Dantz Development Corporation may respond to issues within this forum. Dantz is under no duty to provide a response to an issue, or to do so in a timely manner.

 


 

A DAntz employee asserted, in this firum, that it was possible to restore the correct attributes and stated that he was able to do so.

 

I responded by asking for the steps used.

 

Such a response is appropriate for this forum.

 


 

I have yet to receive a proper response to this thread.

Link to comment
Share on other sites

Hi Howard,

 

 

 

Here is how this works for me:

 

Make sure the "clear archive bit" setting is not on.

 

Back up a subvolume on your machine.

 

Then do a "restore entire disk" to another folder on the same machine.

 

 

 

Please post which attributes don't match up.

 

 

 

Nate

 

 

 

 

Link to comment
Share on other sites

Quote:

natew said:

Hi Howard,

 

Here is how this works for me:

Make sure the "clear archive bit" setting is not on.

Back up a subvolume on your machine.

Then do a "restore entire disk" to another folder on the same machine.

 

Please post which attributes don't match up.

 

Nate

 

 

 


 

The "clear archive bit" is not set when I run a backup from my scripts.

 

My scripts backup all 10 logical volumes on the 3 internal SCSI drives.

 

When I first ran my experiment, a long time ago, I reported here that the Read-only bit was not getting restored when the content of the file was unchanged, but the read-only bit had changed.

 

I ran that experiment using the selected files option, instead of the all too dangerous restore entire volume option.

 

Since I first ran that exoeriment, there have both RDU and software updates to 6.5.

So, I reran the experiment and this time it worked, i.e., the correct changed attributes were restored.

 

As far as I know, I did nothing differently in the two experiments, so I can only conclude that there was a bug in the earlier software, using the "selectetd files", or whatever it is called, Restore option.

 

Apparently, changed attributes are saved in the latest snapshotm even if there is no match cruteria to causew the file content to be again backed up.

 

So my conclusion must be that I encountered a situation in which a snapshot was not updated for the particular volme when no files had to be backed up.

Link to comment
Share on other sites

Hi

 

It is possible that the snapshot had some incorrect information. My understanding is that if you want restored attributes and file permissions to match exactly you need to use the "restore entire" or "replace corresponding" restore option to a sub-volume.

 

Either way I'm glad to hear it is working the way you expected it to.

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

Hi

 

It is possible that the snapshot had some incorrect information. My understanding is that if you want restored attributes and file permissions to match
exactly
you need to use the "restore entire" or "replace corresponding" restore option to a sub-volume.

 

Either way I'm glad to hear it is working the way you expected it to.

 

Nate

 


 

It would make no sense to rquire use of "restore entire" or "replace corresponding".

Instead of guessing on how this works, it would be rather trivial for Dantz's developers to state what is the required behavior and DOCUMENT this in a knowledge base article.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...