Search the Community
Showing results for tags 'afp'.
Found 4 results
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.
(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....
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.
I set up my production backups on Retro 18.104.22.168 (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