Jump to content

roobieroo

Members
  • Content count

    63
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by roobieroo

  1. I have two client sites that I use Retrospect with and back up a QNAP at one and a Synology at the other. Retrospect is 16.5.1. Performing the initial scan of the QNAP is very fast and it will scan about 5TB's of data of 1.2 million files in 15 minutes while the Synology takes about 1.5 hours to scan just 1.5TB's of data of 850,000 files. Both locations have the same Mac Mini running Mac OS 10.14. The QNAP backup machine also has more RAM but according to the Activity Monitor, memory is not an issue on the slower Synology machine. Performing file copies from the Synology to the machine running Retrospect is very fast and in line with what I would expect to see. Scanning machines that have the Retrospect client installed is very fast. It doesn't matter if I add the share via AFP or SMB although I have had Retrospect get stuck scanning when using AFP which could be related. When the actual backup finally does get around to happening it copies larger files as expected but smaller files like the .ds_store files is really slow. That part I'm not so worried about, it's the long scanning time that concerns me. I even took a clone of the backup server from the fast location over to the slow server and it backed up just as slowly. It also hung Retrospect when trying to scan when connected via AFP. One thing I did notice is that the Synology shows up as Mac OS Appleshare next to the File System entry but the Synology says Unknown. Can any of you think of some settings that could be causing such slow scan times for the Synology share? It does have a second Synology that mirrors its data and uses Backblaze for cloud backups but looking at the performance monitor of the unit during scanning shows nothing using a ton of resources. Is the slow scan time something that is normal with Synology NAS boxes?
  2. The Synology is a DS918+ with four Seagate ST4000VN008-2DR166's configured as a RAID 5. It's set up for high availably mode with a duplicate DS918+. The file system is Btrfs which now that I've done more digging looks like it could the cause of the difference. It's connected to a gigabit switch on both network interfaces. The QNAP is a TVS-EC1080 with eight Western Digital WD30EFRX-68EUZN0's configured as a RAID 5. The file system is Ext4. It's connected to a gigabit switch with four ethernet ports configured for balanced mode. QNAP even has a marketing page about why they don't use Btrfs and one of the bullet points is that it's slower, especially for high I/O operations. https://www.qnap.com/solution/qnap-ext4/en/
  3. I'm using Retrospect 14.6.1.101 for Mac OS 10.12.6 and I don't have the option to enable or disable fast catalog rebuilds on my disk based media sets under Options because it doesn't show up at all. Grooming is not and has never been enabled for any of the disk media sets. Has this been removed and the documentation is incorrect or should I be able to turn it on for existing disk media sets?
  4. That's a bummer. Thanks for letting me know!
  5. This is from the Retrospect 14 user guide.
  6. I had a computer that I used for test purposes that used to have the Mac server app installed. I've since deleted the server app and the server directory from /Library/Server but Retrospect still shows that this computer requires a server license. How does Retrospect determine what is a server and what is considered a desktop and how can I get Retrospect to no longer think this is a server machine? If I'm backing up a NAS by adding it as a share, does that also count as a separate server license?
  7. I'm doing some testing with a trial version of Retrospect 13 and so far it's working as expected.
  8. With Retrospect 10.5.0(145) on Mac 10.10, I noticed that I am unable to restore some files which seems to be caused by using the deduplication feature. The files that missing during a restore are also located on a file server. My understanding was that Retrospect wouldn't actually take up extra space on the media set for the same file but the fact that I can't even select it to perform a restore is very worrying. I have a number of folders with empty contents during the restore process and sure enough, trying to restore those folders results in Retrospect telling me that there was nothing to restore. It seems that the "fix" is to enable the more strict option to match only files in the same location/path but why should I need to enable that at all? Shouldn't Retrospect show that file even though it's already been backed up on another computer to the same media set? What am I missing here?
  9. Thanks for the reply. Do you know which fix or item # listed in the release notes applies to this issue? Nothing jumps out as applying to what I'm seeing so I apologize for being dense.
  10. This also is a problem with Retrospect 11.5.3. I copied some files from a server to another machine and then tried to restore the files from the computer that I copied the files to. Sure enough, the folder I put them in shows up to restore but the contents of the folder is completely empty. I also can't restore the files that I moved to a new folder on the file server itself. I created a new folder and dragged some files in to the new folder. Now, those files don't show up to restore from last nights backup either, only the empty folder. This can't be right can it?
  11. I was selecting the restore icon and then selecting restore selected files and folders. Doing that would show some folders with no data in them because that data apparently was also copied and backed up to another computer. It looks to be the same bug that another user discovered here- http://forums.retrospect.com/index.php?/topic/150808-retrospect-not-backing-up-certain-files/
  12. After more digging, it appears to be a bug with Retrospect 10.5. If the file has been copied to another computer, a server for example, then it thinks it has already been backed up but does not give you the ability to restore the file. If you happen to know about the missing file, you can search for it and do a restore but if there are many files on the client that copied the files then you'll end up with a bunch of missing data when restore the folder containing those items. Yikes! I'm going to be turing on the option to match only the same location/path on all my scripts. I wonder if this bug still exists in the latest version of Retrospect though.
  13. I'm running into this error on a new machine now so I'm also curious to know what you did to fix it.
  14. I have a few clients running 9.0.2.102 that seem to randomly go missing from Retrospect. The server is running 10.7.3 and Retrospect 9.0.2. I can test the address and add them using the direct IP address but multicast shows nothing. There is no firewall running on the client but it does run Parallels on occasion. Needless to say with computer that obtain an address via DHCP this is a real problem since they don't get backed up. Any tips or advice on how to get multicast working properly with my clients or do I have to statically assign all clients I want to use with Retrospect? It looks like multicast is broadcasting on the loopback address but not the primary ethernet port. Does this give any clues? Here's the /var/log/retroclient.log contents 1336662409: Client version is 9.0.2.102 1336662412: sopsFileLoad: gotBytes=1792 stateSig=53436667 firstVers=201 curVers=201 1336662412: NetStart: starting interface thread 1336662412: netCheckNewInterfaces: found new address 127.0.0.1:0 1336662412: ConnStartListen: starting thread ConnStartListen for 127.0.0.1:0 1336662417: netCheckNewInterfaces: found new address 192.168.123.103:0 1336662417: Turning client initiated discovery on 1336662417: ipludAddMembership: adding membership for 192.168.123.103 1336662417: iplud: multicast advertising on address 127.0.0.1 1336662427: IPNSRegister(0): registered: "Clerical","91c861ed1cb9d982","0.0.0.0:0" 1336662427: ConnStartListen: starting thread ConnStartListen for 192.168.123.103:0 1336662429: notifyServerList: Client discovery packet sent to 192.168.123.50 1336662430: bindToValidBootPort: gServerPID has been initialized to 54 1336662431: SopsSetCurrentIPAddress: 192.168.123.103 1336662431: --- UpdateClientStateWithMonitorEntered: clientState:10 1336662436: netCheckNewInterfaces: found new address 10.211.55.2:0 1336662436: iplud: bind() failed with error 48 1336662440: bindToValidBootPort: task_set_special_port succeeded 1336662444: IPNSRegister(0): registered: "Clerical","91c861ed1cb9d982","0.0.0.0:0" 1336662444: ConnStartListen: starting thread ConnStartListen for 10.211.55.2:0 1336662444: netCheckNewInterfaces: found new address 10.37.129.2:0 1336662444: iplud: bind() failed with error 48 1336662450: IPNSRegister(0): registered: "Clerical","91c861ed1cb9d982","0.0.0.0:0" 1336662450: ConnStartListen: starting thread ConnStartListen for 10.37.129.2:0 1336663027: notifyServerList: Client discovery packet sent to 192.168.123.50 1336671869: connTCPConnection: non-stream packet too large: 101517849 1336671869: ServicePurge: serviceID 0 not found 1336672027: notifyServerList: Client discovery packet sent to 192.168.123.50 1336672060: ServicePurge: serviceID 0 not found 1336672070: ServicePurge: serviceID 0 not found 1336672411: ServicePurge: serviceID 0 not found 1336672417: NetGetMacAddr: This system's built-in MAC address is 3c:07:54:52:86:91 1336672418: SopsSetOnDemandServer: Setting to 192.168.123.50 1336672419: SopsSetFlags: theServer.parms.clientflags = 8602 1336672627: notifyServerList: Client discovery packet sent to 192.168.123.50
  15. roobieroo

    Retrospect 10.5 & FileMaker 13

    Just crate a backup script from the Filemaker Admin interface and then tell Retrospect to back those files up. I have Filemaker set to backup the databases hourly and once each night and have Retrospect backup the nightly backup folder. Works great and no additional scripting is needed.
  16. So are you saying that using incremental backups still caused the entire file to be backed up again when you modified the ACL permissions or did you not try your test?
  17. I have two different locations both using Retrospect 10.5.0(145) and as of yesterday evening they can no longer send email using gmail. I switched to using me.com and that works fine but gmail seems to maintain the connection but it never gets anywhere. I enabled more detailed network logging but no messages are being displayed. It's like the connection takes place and hangs. I can't stop Retrospect in System Preferences unless I unplug the network cable for a bit which drops the smtp connection. If I force quite Retrospect it's corrupted both configurations on multiple occasions and I've had to start from scratch. Has anyone else had these issues just recently with sending via gmail?
  18. For what it's worth, I haven't had a problem with this for quite a while now. I guess it could still be happening but it hasn't been something where I've noticed clients not backing up.
  19. First off, I haven't enabled the "use attribute modification date when matching" since that was totally busted if you used ACL's and I'm not sure if they bothered to fix it with the latest update. I noticed that my clone script is now taking much longer than it did under the previous version of Retrospect which I think was 10.2. Since moving to 10.5, I can run a clone script and then as soon as it finishes, run the script again and it will copy huge amounts of data that has absolutely not changed from the first time the clone ran. I don't know what's so special about the files that it recopies each time or if it's just a bug with 10.5. In addition to the clone script, I also run a backup script which is scheduled to run not too far after the time the clone usually finishes. Both scripts copy all data on the drive but the backup will backup say 4GB's of data while the clone will copy say 30GB's each time even if the clone just finished and I immediately hit run again. Why would Retrospect be cloning so much data right after a clone script has just completed? Again "use attribute modification date when matching" isn't even turned on so why would it think there is so much changed data that should be identical? Is anyone else using Retrospect to clone drives and if so are you seeing similar issues? Mac OS 10.8.4 Retrospect 10.5.0
  20. Neither drive is case sensitive and neither has ignore ownership enabled.
  21. Both drives are physically connected. The source is Mac OS Extended connected with Thunderbolt and the destination is also Mac OS Extended connected with Firewire 800.
  22. Now they just need to make the email messages it sends more useful buy including the name of the client or even better by sending a daily summary of all backup activity. When you're backing up 15-20 clients among multiple locations, the emails sent by Retrospect aren't terribly useful in their current state.
  23. I keep having an issue with my clients which seems totally random and usually it's with a different client each time. For some reason, the retroclient.state file ends up completely empty so then Retrospect says that there is no password. I have to delete the empty retroclient.state, run the installer again and set the password. I know how to fix it but the problem is that each time this happens the client stops backing up until I notice it. Is anyone else seeing this? I'm not sure what triggers the empty retroclient.state file to begin with either I'm afraid. Each client that has had this issue so far is running 10.7.4 or 10.7.5 and Retrospect client 10.1.0(221). This is what I see in the retroclient log file. 1372123932: Client version is 10.1.0.221 1372123932: SopsLoad: no public key, return -1.! 1372123932: LogFlush: program exit(-1) called, flushing log file to disk
  24. I have set up a copy script and according to the manual, selecting "overwrite entire volume" for the destination should only remove files that are not the same as on the source drive. Running the copy script again even right after it has completed erases the entire destination drive and copied everything all over again. From the manual "Retrospect saves time by not copying identical files, that is, files that share the same location, name, modification date and time, etc., that are already present on thedestination." but that is clearly not what is happening. I do have use attribute modification date when matching enabled as well. What is the point of scanning the entire destination volume during the copy if it's just doing to delete the entire drive and start over from scratch? Is this a bug? How can I keep a clone without having to recopy identical files on the destination every time? Retrospect 10.1.0 (221) running on Mac OS 10.8.4
×