Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About martyrs29

  • Rank
    Occasional Forum Poster
  1. Hello Foster. Amcamc originally posted this thread with both clients and the server running Windows 2003. He only recently added the comment about the NAS device with a UNIX file system. He has also stated above, just as I have, that not backing up the security information on Windows clients is just not an option. You said that the folder level security information will still be available via the backup snapshots. With this being said, I still don't feel comfortable turning off this option. On a side note, if turning off the backups of security information doesn't actually turn it off, why is that option even there? For whatever reason, my issues with the backups of duplicate files seem to be tied to the archive bit and archive bit alone. Until EMC comes out with a fix, I have to use an exclude statement that will not back up files with the archive bit cleared. This works with disk backups because I can use the grooms to keep the backup sizes under control, and I don't ever have to recycle the backups. My file backup sets, however, are more of a problem because I have to remove this exclude statement on the first backup after the recycle. Makes backup administration quite annoying.
  2. martyrs29

    always restarting client

    Hey Rusty. Thanks for this info. Are you backing up to a NAS or SAN? I've seen the issue you are referring to when I have several (usually four or more) executions running where they all are accessing the same NAS. This problem disappears, however, when I moved the backup sets to a SAN. I'm not sure if it was a throughput issue, and IO issue, or what, but that was my only fix for that problem. I don't think it was a throughput issue, as both the backup server and the NAS it was connected to were utilizing Gig NICs connected to a Gig switch. Then again, I'm still not ruling this out.
  3. Hey Tommy. Thanks for the post. However, I have verified that none of my clients are set to READ ONLY. I'm not sure what other files this is happening to, but the files that I notice this strange activity on happen to be SQL .BAK and .TRN files on SQL servers, in addition to .tmp mail files when backing up Mail servers. I guess the reason I notice it more on these files is because there are so many of the .tmp files and some of the .BAK/.TRN files are several Gigs in size, causing all kinds of space issues in our SAN environment.
  4. It is not acceptible to NOT backup the security information on a Windows machine. In the event of a bare metal restore, the machine would essentially be wide open. With that being said, the security information is in no way being modified in each instance I'm seeing this issue. The only software that is modifying the file at all is Retrospect, when it clears the archive bit. If you would like any more information to help describe the problem we are having, I would be happy to provide you with it. As I said, I have an open issue with EMC on this, to which I'm getting very little feedback. I have sent them screen shots showing the duplicate files, and I can provide more if necessary.
  5. martyrs29

    always restarting client

    Hey Rusty. Does this happen if it is the only execution unit running? In other words, are there several executions running when this seems to happen? What version of Retrospect is running on the client?
  6. Is anyone else having this problem, or is it just a handfull of us? EMC has no news for me because they cannot duplicate the problem. However, mine is duplicated on a daily basis.
  7. martyrs29

    always restarting client

    What error is being logged at the time the backup fails? (i.e. network communication failure, backup client reserved, etc.) What OS is the client running?
  8. Hey RoyG-RTI. I have a feeling that even in version 7.0, Retrospect would back up the file again if the archive bit was different than its initial backup. Is there any way you can perform a small test on this and let us know? Check out your snapshots from the two backups and see if the same file is listed twice, once with the archive bit flagged and once without. The only way you'll be able to do this, however, is if you can get your AV software to modify the bit between backups. Let me know what you find! In my case, my problem isn't so much that Retrospect isn't ignoring the archive bit, but its actually modifying it after the file is backed up! But even one step more than that, Retrospect backs up the file again, not knowing that it was itself that changed the file. I'm curious to see what RoyG-RTI finds, and whether or not this problem has been there all along and I just haven't noticed before.
  9. Is this possibly a bug in the software, or does Retrospect check the available physical memory in the machine to try and pre-allocate the memory to a particular backup/transfer. This is the only reason I can think of that would cause a backup/transfer to fail without the performance monitors showing a lack of available memory. If Retrospect allocates memory as it needs it, then I should be able to see via the performance monitors that the machine is indeed out of memory for the backup. Is anyone else having this kind of problem, or is it just me and asatnik11?
  10. I am also seeing this. I have an open issue with EMC on this (issue # 1-7509567). However, in my case, I found the following... Upon performing the first backup, any files with the archive bit flagged would be cleared. Then on the next backup, the file would be backed up again because the archive is now cleared where it was not the first time around (so Retrospect thinks the files are different). This is causing major space issues for some of our clients where we back up their SQL .bak files and mail .tmp files. Upon speaking to someone at Retrospect, they claim that in Retrospect version 7.5, Retrospect started "using" the archive bit. This makes no sense to me since Retrospect's claim to fame was that it did not use the archive bit like most backup software, but rather based everything on its snapshots. Upon mentioning this to the technician at EMC, they clarified by stating Retrospect still uses snapshots, but it will clear the archive bit from those files it backs up. Well, when Retrospect is modifying the archive bit it is actually changing the file in the eyes of the snapshot (hence another backup of the file, even though it has not changed). I have tried following up with EMC several times on this, but I have not heard from them since I provided them with screenshots showing the file being backed up twice with the same size etc, but the archive bit cleared in one instance and not the other.
  11. After upgrading to 7.5 Multi-server for Windows, we are all of a sudden receiving many -625 (not enough memory) errors that are causing backups to fail. We have 2 GB of DDR PC3200 RAM in our dual 2.8 GHz processor machine, which is all that Retrospect suggests for 8 execution units, and our C drive has over 3 GB available on it (thinking maybe it was the temp folder). Just in case we indeed were running out of memory, I set up performance monitors to poll every 5 seconds on the available physical memory. The lowest it reaches is 600 MB. Anyone else seeing anything like this?