amcmis Posted April 21, 2006 Report Share Posted April 21, 2006 'Allo, Just installed a fresh copy of 7.5 Multi, got the latest update. Installed the client on second server. Set up a script to backup second server to a 'Disk' backup on the primary server. Use the RUN menu to launch it and create first NORMAL backup. All goes well. (around 10GB) So now I use RUN again to do a NORMAL backup expecting it to be very small, just a few changed things on C:... But lo, another 10GB or so goes to the backup, which now, after compression, is 17GB or so. Confused, I RUN a third time, same way, and this time it does the correct thing, backing up just a handful of MBs. So what's up? The first NORMAL would act as a RECYCLE, I know. Is this a known bug about the second? I had this happen with both of the client servers I'm backing up in this way. (In case you are wondering, it's a D-D-T strategy so I can keep the tape drive streaming...) TIA! jth Link to comment Share on other sites More sharing options...
RonaldL Posted April 21, 2006 Report Share Posted April 21, 2006 What OS are you running this on? What OS are the clients? Does this happen with the local c: drive? What type of device are you backing up to? What type of verification are you using? Be sure you're running the 7.5.1.105 update also. Link to comment Share on other sites More sharing options...
amcmis Posted April 22, 2006 Author Report Share Posted April 22, 2006 Yup, I missed the details. Win2003 Server Std 32bit all around, latest patches. 7.5.1.105 too. My test only includes Retro Clients to a local drive, F:, in DISK mode as opposed to FILE mode. I haven't tested C: as a source to F: as a destination, since it would be silly. Eventually I back up all local disks to a LTO2-L drive, but haven't seen this behaviour yet there. (Doesn't mean it hasn't happened, just haven't seen it...) I was using no verification at the time. I will try a couple more tests tomorrow to see how often I can reproduce it. jth Link to comment Share on other sites More sharing options...
retro_user75 Posted April 28, 2006 Report Share Posted April 28, 2006 I have the same problem with version 7.5 not doing incremental backups with all the volumes, including the local disks at the Win 2003 server, plus all the networked volumes. Please see my post about "proactive backup fails to do incremental ...". Please let me know if you find the answer or have any ideas. Thanks - Achilles Link to comment Share on other sites More sharing options...
martyrs29 Posted May 2, 2006 Report Share Posted May 2, 2006 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. Link to comment Share on other sites More sharing options...
RoyG-RTI Posted May 3, 2006 Report Share Posted May 3, 2006 Just great! As you said, the claim-to-fame and reason we went with Retrospect was that it didn't care that our virus scan messed with the "dirty" bit. So one good reason NOT to upgrade my 7.0 to 7.5 - - - I was just thinking about that. RoyG-RTI Link to comment Share on other sites More sharing options...
martyrs29 Posted May 3, 2006 Report Share Posted May 3, 2006 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. Link to comment Share on other sites More sharing options...
RoyG-RTI Posted May 3, 2006 Report Share Posted May 3, 2006 I am still testing the "repair" to another problem (which I will be posting about shortly) so I can't do the test right away. In a day or two I'll take a shot at it. RoyG-RTI Link to comment Share on other sites More sharing options...
martyrs29 Posted May 9, 2006 Report Share Posted May 9, 2006 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. Link to comment Share on other sites More sharing options...
MiGru Posted May 9, 2006 Report Share Posted May 9, 2006 We had the same problem at two different machines (didn't test any further machines). For more details please see my thread "The great new Version 7.5" http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Number=69441&page=11&view=collapsed&sb=5&o=&fpart=1 We now switched back to Version 7.0 and the error did not occour again. Link to comment Share on other sites More sharing options...
nekr0phage Posted May 9, 2006 Report Share Posted May 9, 2006 Hi, If you look at the changelog for 7.5 the first item listed under "Tips and Late-Breaking Information" discusses the use of the archive bit for file level security information: http://kb.dantz.com/article.asp?article=8331&p=2 Basically, 7.5 uses the same methods as 7.0 to compare files and determine what is new or changed. Now, in addition to this, it will check the archive bit on a file to determine if security information for that file has been changed. This is an optional feature that can be disabled by unchecking the option to "Backup up file security information for servers/workstations" in the script's options under Windows>Security. If you have other applications that modify the archive bit, it may be a good idea to disable this option. Link to comment Share on other sites More sharing options...
amcmis Posted May 11, 2006 Author Report Share Posted May 11, 2006 Whoa, I've been away and had no idea this thread piqued everyone's interest so much! OK, here's what I just did, and it's worse than I thought originally. I am doing a backup of a NAS box, so it's a SMB mounted share. (Buffalo Terastation v1) My destination is a "Disk" backup, which happens to be a 134GB disk at this moment. (Yup, I know this can't work in the long run!) My backup set is set to groom via "Retrospect predefined policy." For the test, I ran the first normal backup at 4:00 yesterday, and it backed up maybe 50GB of files, compressing about to 35GB in the destination directory. The Terastation had 2 shares, one with 1181 files, the other with 77968. It took 2:39 to complete. All good. The scheduled backup was for 9:00 last night, so I went home with crossed fingers. This morning, I looked and found yes, the backup ran, showing as 'normal', but took 2:57 to complete. And guess what, my backup set has 4 sessions now, with 1181 and 77968 files re(tro)spectively listed in the nighttime one, identical to the first one. My destination directory is now at 70GB. With fingers now uncrossed, but having read the archive bit stuff in this thread, I run the third normal backup. Well, it's 1:24 into it and 26GB completed. I am assuming my backup container will be around 105GB by the end of the third backup. THIS IS A SERIOUS PROBLEM!!! 2 I might live with, but every backup? The only solution I can think of is to do a Recycle every night. It would probably be shorter. Is this happpening with Tape as well? That would be extremely rude. amcmis EDIT: I did check the Security section, which was set to back file and folder for Servers, not Workstations. Does Retro call a generic NAS box a Server? And besides, there is no AV or other processes outside of Retro touching these files, to my knowledge. (Unless Buffalo RAID5 implementation is to blame? XFS file system?) Link to comment Share on other sites More sharing options...
amcmis Posted May 11, 2006 Author Report Share Posted May 11, 2006 OK, that was it on the Terastation. I cleared all of the security checkboxes and it worked. Shall I blame the Samba implementation of these NAS boxes as the culprit? This probably doesn't address all of the issues in this thread, as server security info from Win boxes does need to be backed up. And I'm still not happy that Retro cannot backup Security changes without backing up the WHOLE file again, per the TechNote. Link to comment Share on other sites More sharing options...
nekr0phage Posted May 11, 2006 Report Share Posted May 11, 2006 Hi, It's not your connection method that is the problem, it's your file system. The Buffalo Terrastation uses the XFS filesystem which was originally developed for IRIX (a UNIX variant) and eventually released under the GNU GPL. This file system will not handle permissions in the same way an NTFS system would. If you were to take the data on your Terrastation and dump it to an NTFS volume I doubt you would encounter this repetitive backup. For more on XFS: http://en.wikipedia.org/wiki/Xfs Link to comment Share on other sites More sharing options...
martyrs29 Posted May 11, 2006 Report Share Posted May 11, 2006 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. Link to comment Share on other sites More sharing options...
TaTommy Posted May 12, 2006 Report Share Posted May 12, 2006 The answer for me was to make sure that the restrospect cleints are NOT set to "read only". Appareantly the server can't keep track of which files were already backed up if the "read only" option is checked. (The starting happening to me after I did an upgrade a while back. The "older" version didn't matter. In other words, even with the "read only" option enabvled it still did normal backuped correctly) Tell me if this works for you. Tommy Link to comment Share on other sites More sharing options...
martyrs29 Posted May 12, 2006 Report Share Posted May 12, 2006 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. Link to comment Share on other sites More sharing options...
nekr0phage Posted May 15, 2006 Report Share Posted May 15, 2006 Quote: 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. Amcamc is not backing up a Windows volume. He is backing up a volume from a NAS device with a UNIX file system. No one is disputing that file level security information is desirable, but in many cases it is not absolutely necessary. In addition to this, folder level security information will still be available via the backup snapshot, so the system would not be completely wide open due to hierarchical restrictions, as well as whatever account security is in place to monitor initial access to the system in general. I merely suggest disabling backup of file-level security information as an attempt to diagnose the problem. Once the problem has been pinpointed appropriate action can be chosen based on an individual environment's requirements. Link to comment Share on other sites More sharing options...
martyrs29 Posted May 15, 2006 Report Share Posted May 15, 2006 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. Link to comment Share on other sites More sharing options...
nekr0phage Posted May 16, 2006 Report Share Posted May 16, 2006 Quote: On a side note, if turning off the backups of security information doesn't actually turn it off, why is that option even there? Hi, If you take a look in the options for any backup script you'll see that it is not one single option to backup security information. There is an option to backup folder level security information, and the new option to backup file level security information, both of these options are available for server machines and workstations for a total of four options. Link to comment Share on other sites More sharing options...
marsoft Posted May 17, 2006 Report Share Posted May 17, 2006 Hi all, I am having the same problem. I am running under WinXP-Pro. Does anyone know how I can download 7.0. I still have my key but have lost the installation files. Thanks, Larry Link to comment Share on other sites More sharing options...
nekr0phage Posted May 17, 2006 Report Share Posted May 17, 2006 Hi Larry, You can get the 7.0 installer and updates from the updates section of the site, here: http://emcinsignia.com/supportupdates/updates/retrospect/archive/#UPDATETYPE41 Link to comment Share on other sites More sharing options...
marsoft Posted May 18, 2006 Report Share Posted May 18, 2006 Hi Foster, Thanks for the info - I have reinstalled 7.0 Larry Link to comment Share on other sites More sharing options...
AmyJ Posted May 18, 2006 Report Share Posted May 18, 2006 If you drill down into one of your backup sessions and get Properties on one of the files that absolutely should not have changed since the prior backup what does it say next to "Flags"? What kind of Verification are you using during backup? Link to comment Share on other sites More sharing options...
algilson Posted July 18, 2006 Report Share Posted July 18, 2006 We're having the same problem. When I drill down on a file that definitely has not changed, but yet has been backed up 4 times, I get: Drill down on first backup: 001H1202.JPG Flags: Marked, Archive Type: File Size 1,905K total (1,941,818 bytes used) Location: Clipart\ December 2002\ Photos\ Created: Friday, September 26, 2003, 7:13:25 AM Modified: Friday, November 01, 2002, 10:15:40 AM Accessed: Friday, March 03, 2006, 5:43:18 AM Backed up: Sunday, April 02, 2006, 11:16:56 PM Drill down on second backup: 001H1202.JPG Flags: Marked, Archive Type: File Size 1,905K total (1,941,818 bytes used) Location: Clipart\ December 2002\ Photos\ Created: Friday, September 26, 2003, 7:13:25 AM Modified: Friday, November 01, 2002, 10:15:40 AM Accessed: Wednesday, April 05, 2006, 7:42:34 AM Backed up: Friday, April 21, 2006, 8:07:23 AM Drill down on third backup: 001H1202.JPG Flags: Marked Type: File Size 1,905K total (1,941,818 bytes used) Location: Clipart\ December 2002\ Photos\ Created: Friday, September 26, 2003, 7:13:25 AM Modified: Friday, November 01, 2002, 10:15:40 AM Accessed: Wednesday, April 05, 2006, 7:42:34 AM Backed up: Monday, April 24, 2006, 8:29:50 AM Drill down on fourth backup: 001H1202.JPG Flags: Marked, Archive Type: File Size 1,905K total (1,941,818 bytes used) Location: Clipart\ December 2002\ Photos\ Created: Friday, September 26, 2003, 7:13:25 AM Modified: Friday, November 01, 2002, 10:15:40 AM Accessed: Tuesday, June 20, 2006, 3:29:44 PM Backed up: Monday, June 26, 2006, 11:33:33 AM Really hoping I don't need to back this up AGAIN. Verification on the set is set to: Thorough verification. - Al Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.