Jump to content

Opening and using an application after Retrospect is already copying


Recommended Posts

I understand that Retrospect will not back up data from an application that is open. Firstly, is that true? Secondly, if I have all applications closed and run Retrospect, once it has catalogued data and is copying it to the backup catalog in my external hard drive, could I open one application and begin using it (to save time). I'm assuming that's okay, since Retrospect already catalogued the data from that application. Please let me know. Thank you.

 

Richard

Link to comment
Share on other sites

I think you misunderstand the paradigm.

 

Retrospect cannot open files (not applications) that are already open - that's a unix issue. For this purpose, applications may be considered files depending on their file type, and understand that what Mac OS presents to a user as an "application" is actually a bundle of files in a directory (".app"). Depending on how the application has the files open, some data might be backed up, but there is the possibility that it might not be a consistent set of data.

 

Second, retrospect makes several passes over your data. A first pass to figure out what files to back up. A second pass to back them up. And a third pass (optional) to compare. None of this is the catalog. The catalog is an index of the files that have been backed up.

 

And it's "okay" for you to use an application while data is being backed up. But retrospect won't be able to back up open files. That may or may not be what you want.

 

The best backup strategy is to back up a quiescent system with no one logged in.

 

Russ

Link to comment
Share on other sites

Quote:

Retrospect cannot open files (not applications) that are already open - that's a unix issue.

 


 

Are you sure?

 

Unix will certainly not allow a file to be written by two processes at the same time, but if one process opens a file for writing, another process can open that same file read-only, no?

 

Retrospect seems able to backup files that are open, often times resulting in time or data mismatch entries on the Compare pass.

 

Perhaps a certain class of files behave differently; I don't use Entourage or other active databases that Retrospect might happily copy, but result in an unusable Restore. But I would think that would be application dependent, and not OS dependent.

 

Dave

Link to comment
Share on other sites

Quote:

Are you sure?

 

Unix will certainly not allow a file to be written by two processes at the same time, but if one process opens a file for writing, another process can open that same file read-only, no?

 


 

Yes, if you don't quote out of context and take the full quoted paragraph:

 

Quote:

Retrospect cannot open files (not applications) that are already open - that's a unix issue. For this purpose, applications may be considered files depending on their file type, and understand that what Mac OS presents to a user as an "application" is actually a bundle of files in a directory (".app").
Depending on how the application has the files open
, some data might be backed up, but there is the possibility that it might not be a consistent set of data.

 


I didn't want to go into a treatise of the various flags that can be passed to the various variants of open():

Quote:

The flags specified are formed by or'ing the following values

 

O_RDONLY open for reading only

O_WRONLY open for writing only

O_RDWR open for reading and writing

O_NONBLOCK do not block on open or for data to become available

O_APPEND append on each write

O_CREAT create file if it does not exist

O_TRUNC truncate size to 0

O_EXCL error if create and file exists

O_SHLOCK atomically obtain a shared lock

O_EXLOCK atomically obtain an exclusive lock

 

 


 

There's no way to predict how a particular application might be opening a file. And some applications will do an unlink() after opening a file so that it is no longer in any directory but the program still has a file descriptor for the file, thereby creating a temp file that can only be accessed by the opening/creating program.

 

I apologize if my statement was interpreted to mean that it is only possible for one process to have a file descriptor open at at time when I instead meant that, depending on how the application is written and how it is accessing its files, it may not be possible for Retrospect to open / back up / or, in some cases (unlink()), even to be aware that such a file exists. I just didn't want to go into a treatise.

 

And likewise, depending on the file type of the application itself (identified by its magic number), it may not be possible to open the application for backup while it is executing. See, e.g., "man a.out".

 

There was another undercurrent to my post, namely, that some sets of files have to be backed up as a set. The Cyrus database is an example - you must have the Mac OS X Server mail services off while you back up the Cyrus database or else you end up with a corrupted mail store on restore. I think that the mail.app files may be similar for imap accounts, and Entourage has its own issues. So do the accounting programs that we use.

 

My whole point, without going into a treatise, was to say that you really can't trust a backup to provide a good restore unless the machine is quiescent.

 

Russ

 

Russ

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...