Jump to content

Search the Community

Showing results for tags 'afp'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Announcements, News and Resources
    • Latest News
  • Windows Products-Retrospect
    • Professional
    • Server, SBS and Multi Server
    • Device and Hardware Compatibility-Windows
    • Exchange Server Add-On Support
    • SQL Server Agent
    • Linux, Unix and Netware Clients
    • Express for Windows
    • Product Suggestions-Windows
  • Mac OS X Products-Retrospect
    • Retrospect 9 or higher for Macintosh
    • Retrospect 8 For Macintosh
    • Retrospect 6: Desktop, Workgroup and Server for Mac OS X
    • Device and Hardware Compatibility-Mac OS X
    • Linux Clients
    • Product Suggestions-Mac OS X
  • Macintosh OS 9 and Earlier-Retrospect
    • Express, Desktop, Workgroup and Server for Pre-OS X
    • Device and Hardware Compatibility Pre OS X
  • General Discussion-Retrospect
    • Networking and Clients
    • Strategy, Scripts and General Use
    • Retrospect iPhone App
  • Retrospect 8.x for Mac
  • Retrospect 6.1 for Mac
  • Retrospect 7.7 for Windows
  • Retrospect 7.6 for Windows
  • Retrospect Express
  • General Discussion


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 5 results

  1. Greetings! Running Retrospect Server 16.6.0 (114) on a MacPro trashcan updated to Catalina 10.15.3. Currently there are no 'client' machines, I'm simply backing up 5 shared volumes on a Synology RS2414rp+ (also current DSM) to LTO-6. I've added the shares via Sources using 'afp://myFileServer.local/Share_Name', and set it to log in using a registered user with admin privileges. The shares all show up in Sources with the green status indicator. Backup scripts are set up to run after hours, and I've got a 5-member media set, two blanks, and a cleaning tape in my 8 slot robot. All Good, right? Nope. Shortly after a script starts, Retro begins scanning. Then it hangs and I get a macOS system alert saying the server is shutting down. After that, my Retro log fills with 'file not found' errors and nothing gets backed up. Checking the Sources pane after this, the target volume shows as disconnected. Status goes green again via either Browse button or Locate. Any ideas? Thanks in advance!
  2. I have roughly 3 Terabytes I need to backup daily, I understand the instant scan can improve performance, but it usually averages out to the low 900MB/minute. Is there a way to improve Retrospects performance or is this as good as it gets? Current Config Backup Server Retrospect Server 12.0.0 Xserve 2008 2.8 QC 6GB Memory Mavericks 10.9.5 ATTO UltraSCSI Express UL5D (320 MB/s) SCSI Array Promise vTrak M310P RAID 50 (12xWD20EFRX RED) 1MB Stripe 4KB Sector Client Server Retrospect Client 12.0.0 Xserve 2008 2.8 QC 6GB Memory Snow Leopard 10.6.8 ATTO Xtend SAN iSCSI Initiatior w/Marvell Yukon 88E8061 GbE Card iSCSI Connected on Dedicated HP Procurve Switch 1800 Jumbo Frames iSCSI Array Promise vTrakM610i RAID 10 (12xWD10EACS GREEN) 64KB Stripe 512 Sector Performance Test 1 AJA System Test 10.5.2 Sweep File Sizes Test Backup Server to SCSI Share W:171.9MB/s R:216.7MB/s Client Server to iSCSI Share W:77.6MB/s R:79.8MB/s Backup Server to Client Server over AFP W:58.2MB/s R:60MB/s Performance Test 2 Retrospect Server 12.0.0 45 GB Mixed Media Share Block Level No Compression Media Verification Only Source:Client Server Using Retrospect Client: 1,616.6 MB/minute (26.94 MB/s) Retrospect using AFP Share: 2,238.6 MB/minute (37.31 MB/s) Retrospect using iSCSI Share: 2469.9 MB/minute (41.165 MB/s) The iSCSI Share ignored ownership permissions, i would assume the AFP Share Ignores them as well.
  3. (env: retro 10.2.0 (201) on Mac OS X 10.8.x) I have re-configured my volumes and have eliminated the need for one of my remotely mounted "sources" on the retro sever. finished the reconfig, and removed the AFP volume "backup" from the source list in the console. Since I had removed the volume from the export list on the server, I wanted to make sure that it was truly no longer accessible to the retro engine, so I tried to re-mount it. It worked (!) I found that when you remove an AFP volume from the source list, it does not necessarily unmount the volume. This may be right, and might be wrong, but it was unexpected. FYI....
  4. I have been trying to get several AFP shares to work. I have several local machines running Mac OS X, and a couple of NetBSD servers running Netatalk. The problem I have is that once I choose a "source" at a particular URL - afp://mercy/backup, for instance, that is the ONLY volume that retro will mount. No matter the URL I give to retro, it will only mount that share. If I unmount the share (from inside retro) and re-mount a different AFP volume, I can "browse" the contents, and I get the "other" volume. Sometimes I can get a second volume to mount. However, the data (if I browse the content) is actually the "stuck" volume. On occassion, I can mount a second volume while the first is still mounted, but the volume name comes up as a duplicate of the "stuck" one. it appears that restarting the engine can *sometimes" free up retro to mount a different volume without unmounting the "stuck" one, but the name of the volume is always the same as the stuck one (regardless of what volume I choose) This is a pretty serious bug. It makes it impossible to put these NAS shares on a backup schedule.
  5. I set up my production backups on Retro (engine on Mac OS X 10.6) yesterday, and put my backup sets on an AFP volume (shared storage with the old backup server. Old server exporting the disk via AFP) I watched retro run until bedtime. It was pretty busy. The console response was sluggish and slow, but working. When I got up this morning, Retro had clearly crashed at 8 AM, judging from the "startup" in the Retro log, but some operations that had clearly happened (files in media sets, but nothing in the log about the script(s) that put them there) There was a retro 6.1 rebuild active, and a list of backups that ran overnight. Judging again from the log, it looks like the backups were so sluggish that they did not finish, by 6 am, triggering the "stop" time to terminate the scripts (?) I don't know what happened in detail. I am only judging from the logs. The log and the assert log (attached) are included below. 8AMcrash.txt.zip log-8am-crash.zip
  • Create New...