Jump to content

Lennart_T

Members
  • Posts

    4,151
  • Joined

  • Last visited

  • Days Won

    74

Everything posted by Lennart_T

  1. For my former employer, I managed Retrospect as a small part of my job. We had about 70 computers, divided into 4 disk backup sets. The clients were divided by platform (Mac/Windows) and then by department (development vs. others). Each group of clients had their own backup set. So we had four executions running at the same time. Then we had a tape backup set for off site storage. Every weekend we transferred from each of the four disk backup sets to the tape backup set. The disk backup sets were then groomed. Perhaps you could do something similar: Having four small backup sets, groomed to keep the last (say) three backups and one large disk backup set, transferring the last backup/snapshot for each client from the small sets to the large every night.
  2. Yes, Yes and No* *) I'm almost 100% sure that data deduplication was part of Retrospect 3, which was the first version I used. Yes, of course. A backup set doesn't "know" about any other backup set and its contents.
  3. Yes, that is the default (and has always been). However, Retrospect also looks at the file metadata, so a file that has identical content, but different modification date (for instance) will be backed up twice. That means that a lot of Windows' files will be backed up multiple times, even if seemingly identical, because their metadata is different. Windows updates, for instance, does not run on exactly the same time on identical computers, so updated files will be different.
  4. As far as I remember, deduplication has always been one of Retrospect's features. https://en.wikipedia.org/wiki/Data_deduplication I fail to see what that has to do with the number of execution units per backup set. For disk backup sets there has always been one execution unit per backup set. So perhaps you could elaborate on what you expected to happen?
  5. Yes, it does. https://www.retrospect.com/uk/support/kb/script_hooks
  6. Well, Retrospect 10.5 very old and is not supported on such new version of Windows 10. So, most likely will your problem go away by upgrading.
  7. Yes, I understand that. Or maybe I should have used the sad smiley? Agreed.
  8. I'm not familiar with how storage group works. Do they by default use a lot of activity threads simultaneously? For old style activities, using (say) Disk media sets, Retrospect uses one activity thread per activity. As a workaround to your problem, you could set an activity to specifically use thread 1, another thread 2 and so on. And NOT let any activity use "Any activity thread". That way you could limit the number of threads actually used. By the way, this forum is mainly user-to-user. You need to request support here: https://www.retrospect.com/en/support/edition
  9. Tried restarting the Mac itself after setting a lower number of activity threads?
  10. That was my next suggestion. I don't know where you live, but here in Sweden it's about bed time, so Good Night.
  11. I think the key is this: Note: OS X System Integrity Protection may prevent the restoration of protected files and folders to ANOD0015. Try turning it off and see if it helps. NOTE: Turn it on again after the restore. https://www.imore.com/how-turn-system-integrity-protection-macos You must also give Retrospect Full Disk Access: https://www.retrospect.com/en/support/kb/macos_full_disk_access A bit puzzling is the actual error that says invalid file system data as that might indicate there is something wrong with the file system on ANOD0015. What kind of restore are you performing? Have you tried "Restore selected files and folders"?
  12. Can we see the whole log, please? It isn't clear in what stage of the process you get the error.
  13. If it is "blank", then that might be your problem. It has to be formatted and (as David points out) in the correct format.
  14. I think tape stations always have hardware compression. I don't even think you can turn it off (in Retrospect). So trying to turn on software compression is useless, I'm afraid.
  15. That's bad. One workaround would be to schedule both the backup and the transfer to the same execution unit. Then the backup will have to wait for the transfer to finish (or vice versa).
  16. I think Retrospect will wait for the transfer to finish. You don't even have to update the scripts. Just use the "New Backup Set" backup (or transfer) as outlined here, and Retrospect will update the script for you: https://www.retrospect.com/en/documentation/user_guide/win/fundamentals#backup-actions
  17. "Archive" is not a "Copy" and not a "Backup". "Archive" does indeed remove the originals after the copy is done. Only "Backup" uses media sets.
  18. BEWARE that if you happen to lose the originals 10 seconds after you recycled, you better have another backup.
  19. It does NOT. It deletes the unwanted files from the DESTINATION, so both the source and the destination contains the same files. No more, no less.
  20. Did version 6 do this differently? (I mean was able to have multiple sources on a Copy?)
  21. From Retrospect's User Guide at https://www.retrospect.com/en/documentation/user_guide/mac/operations#copying By the nature of the copy operation, you may only copy one Source to one Destination. The source can be a volume or a Favorite Folder from a volume. That means you must use three Copy scripts with three different destinations. From the User Guide: Warning: When you copy all files and folders from one disk to another, Retrospect deletes any data that may already be on the destination volume. Be careful!
  22. In addition to David's excellent advice of the whole procedure, let me just add a little piece of advice: I think you are going one level too deep in the folder structure. You should see the folder containing the RDB files in the list, select it (single-click) and the click OK (not Open).
  23. It is, but only "sort of". When you create a disk media set, you specify how much of the disk it can use. When the ongoing backup is going to reach that limit, a grooming process starts. That happens in the middle of a backup and can take hours. That means the completion of the backup can be delayed by hours. For that reason, it is advised to schedule groom scripts every once in a while. I suggest once every Saturday or Sunday.
  24. Off topic: If you don't know, it's a paraphrase on "Schrödinger's cat": https://en.wikipedia.org/wiki/Schrödinger's_cat
  25. Although I have not experienced that particular error, I think grooming is much more stable in the current version of Retrospect (17.5.x).
×
×
  • Create New...