Jump to content

RetroNudge

Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About RetroNudge

  • Rank
    Occasional Forum Poster
  1. I have been using 7.5.116 CLIENT and have good network throughput. Previous client (one ships with software probably on shelves now) was slow - 10mbps U will have to use the auto update or download the newer client. (note only the client part) To fully test and see if network can be maximized you would - backup over network a very large file from a defragmented client drive - to a defragmented server disk backup volume - on a server with a fast enough CPU that it can calculate the MD5sum for the file faster than network bandwidth can deliver data. If both client and server hard drives were very fast, then network would be the limiting factor.
  2. RetroNudge

    horrible speeds on 7.5

    Rogier ... Please explain... Do you mean that speed is still slow...when using new client 7.5.116... client = Windows Backup server = Mac Yes??
  3. Currently both the server based and client based portions of Retrospect...from Versions 5.1 through 7.5...both modify the "last Access Date/time" of any backed up file to "now" (whenever the backup occurs). Since the retrospect server and client programs both each gather all details about a file before backing up its data...(Creation date, Modify date, Access date, Modified bit, Read only bit, etc.) I personally have large numbers of directories on my servers that none of my users ever goes and accesses, and that none of my server utilities ever accesses. It would be kind of nice to archive them away...once I can verify they are unaccessed for a time. I assume I am not alone in this. It is simple to either open the file in backup mode or, if this still modifies the access date, make one additional OS call to "SetFileTimes" (after backing up data & closing file) to set the access date/time back to what they were before retrospect began using them. Yes, others note that Windows itself and many other utitlities modify the access time...irrelevant. Retrospect shouldn't and can easily not do so with very little effort. This might not be true with backing up "already opened files", however these represent such a small percentage of files that there is no need to change how these are performed. (access time will be when other application closes file anyway).
  4. RetroNudge

    Any word on release of new 7.5 client?...the Fast one?

    Thanks Waltr, If you notice I started that thread What I'm saying is it is possible, without too much effort, to not modify the access date. There are several file copy utilities out there that specifically allow you to choose whether to modify the access dates of files they copy. XXCOPY and ROBOCOPY to name two. All that is required is a API call to getfiledateinfo before backing up the file, and a call to setfiledateinfo after backing up the file. (no, thats not the exact function name, but I have myself written C++ code to use the right one before, I just don't want to look it up right now) Note: these calls would only be necessary for those versions of windows that change the access time when the file is opened and read in 'backup' mode. As I said, the programming is VERY simple...and as such...if they are going to release a new client anyway...why not add this ability there.
  5. RetroNudge

    Any word on release of new 7.5 client?...the Fast one?

    6. Also - When coding perhaps they could fix (for the client) to open the files in backup mode so that the last access time of each file isn't changed.
  6. RetroNudge

    Normal backups, backing up too many files.

    This raises an interesting question...which is: Question #1 - What changes to a file should require backing up the data portion again? Should a change of last access date require backup? Change in which flags should require data portion backup. File Size: Yes Archive: Yes Read Only: No System: No Hidden: No File Owner: No File Security rights: No Access Date: No -- Definitely not, as retrospect erroneously changes this itself. Creation date: Yes, but only if archive bit and/or file size changed. Modified date: Yes The changes in the flags should be backed up...and stored in whatever retrospect uses for a database of directory information...but not the file's data again. Question #2 - When GROOMING backup... Does retrospect compare the MD5 sum of identically named files, and if they are identical, keep only one copy? If not...why not.
  7. 1. Current 7.5 client release has major network speed bug (10MB/min). 2. Present solution is to use earlier 7.0.xxx client to achieve acceptable backup speeds. 3. Information "Iside This Thread " claimed a new release of client was going to be made...and would correct this (and other) problems. 4. The last release was over 2 months ago (2006-02-07). Since this is a code fix not a complete re-write I would assume this could be done quickly. 5. I also would presume some testing of network backups of a a $500 piece of softare was performed and that this sort of BIG BUG would be detected before release.
  8. Walt, I agree...somewhat...that MS screwed up in several of their programs changing the access date. Ok...now we know I agree about that. -- But, if little Jimmy jumps off the garage roof, does that mean that Retrospect should copy him? If ya shouldna doit, donna doit.
  9. Two simple ways come to mind 1. Go to "dos mode" with Run-> Cmd.exe 2. Navigate with "cd" command to the directory you want to view 3. Type "dir /TA" which displays the "access" as the date Or when using a file explorer window... 1. Choose "view details" 2. Right click on any of the column headers 3. Choose "More..." 4. Checkbox "Date Accessed" and click [ok] (Note: The "file properties changes modified time" has been kind of a joke for a while now another windows programming team bug was when viewing any kind of executable under in the file explorer of windows 98 and probably Win ME would also change the access time. They have to go into the file to get the icon to display it with...but really thats not what file access means...it means launching or parsing through... Access: Reading the file for the purpose of intentionally using the contents of the file. This does not include: getting icons, backing up, grepping or searching for text within listing name in a directory listing.
  10. RetroNudge

    How Long to Rebuild Catalog for a 48GB backup?

    Hmm, Complete newbie here (to retrospect issues), IT guy though. Please specify: Version of retrospect: Backup set medium: ie a tape, hard disk If tape, what kind: DDS 3, AIT 2, DAT 72 Interface to medium: SCSI 2, SCSI 320 LVD, SATA Interface to catalog Hard drive: (same list as above) CPU of machine performing the rebuild: Pentium 4, Athlon XP 64, Duron, etc. Also you might check the CPU % usage on the server. Any one of these might be a limiting factor. As an example, calculating MD5 sum digests on a Duron 800 can't be any faster than about 240mb/min (with the MD5 code EMC is using).
  11. The "last access" time of each backed up file on the client gets changed to backup time. I am using Server version 7.5 (and client version 7.0.xxx because 7.5 client is broken til next fix is released) I have not found any reference to this in the manual, nor (so far) online. Microsoft has documented functions for opening files in "backup" mode, which shouldn't affect the access time. Even if it did, the documentation states that if you really arent modifying the file you should use 'updatefiletime' function and set the access time back to what it was before you got there. Anyone know if the 7.5 client preserves (will preserve) the access time (like it should)? I haven't the heart to upgrade the client again until the speed improves.
  12. RetroNudge

    horrible speeds on 7.5

    Just purchased 7.5 Found the backup speed unacceptable (10mb/min) Found this thread (after some searching) and downloaded 7.0.xxx client. Backup speeds now acceptable. However, the "last access" time of each backed up file on the client gets changed to backup time. I have not found any reference to this in the manual, nor (so far) online. Microsoft has documented functions for opening files in "backup" mode, which shouldn't affect the modify time. Even if it did, the documentation states that if you really arent modifying the file you should use 'updatefiletime' function and set the access time back to what it was before you got there. Anyone know if the 7.5 client preserves the access time (like it should)? I haven't the heart to upgrade the client again until the speed improves. (BTW: Speed of backup, when using disk-disk-tape, [7.5 server <-> 7.0 client] seems to be mostly dependant on the CPU speed of the 'server' machine. Apparently it is spending its time calculating the MD5 sum digests over the files. CPU usage goes to 100%. When backing up a stream of smaller sized files the speed slows due to new file processing overhead or perhaps client opening file time)
×