Jump to content

roobieroo

Members
  • Posts

    66
  • Joined

  • Last visited

  • Days Won

    2

roobieroo last won the day on October 18 2013

roobieroo had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

roobieroo's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

5

Reputation

  1. I've seen this now at a number of client sites where if a client computer has a Mac OS update that hasn't been installed it can't be backed up by Retrospect. If the user installs the update then Retrospect goes back to working normally. This means that clients are constantly missing getting backed up because they have a Mac OS update that they may not even know about waiting to be installed. If I go to the Retrospect server I can still connect to the affected computer but the Macintosh HD is not available to browse until after the OS update is installed. Short of disabling automatic Mac OS updates, is there anything that can be done with Retrospect?
  2. I don't know if this is the same issue but I've had a number of machines have the hard drive go offline when a Mac OS update is waiting to be installed. In the most recent example it was because there was a Big Sur update. Installing the updates and rebooting fixed it. I also noticed that favorites may not work when this happens but stopping Retrospect server using the system preference and starting it back up resolves it.
  3. I have the same issue even with those items checked to allow full disk access. Most of the data on the Synology backs up just fine. It seems to be only Applications/installers on the NAS that generate this error message or if a user copied items to the NAS that would normally require full disk access such as their Library folder. It's helpful to have commonly used installers on the NAS so people don't have to search for and download them but it's also a pain since it generates tons of error messages in the log during every backup. If you find a solution to this I'd love to know what you did.
  4. 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/
  5. 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?
  6. 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?
  7. 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?
  8. I'm doing some testing with a trial version of Retrospect 13 and so far it's working as expected.
  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. 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?
×
×
  • Create New...