Jump to content

Lennart_T

Members
  • Posts

    4,177
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Lennart_T

  1. Just make sure the license code is for version 17.5 and not for (for instance) 16. The account ID should not matter. Copy and paste from the email with the license code is always better than typing.
  2. I'm pretty sure that Retrospect will not perform a full backup just because the files are on another drive. That is because it's the same computer with the same Windows version.
  3. The first script starts by grooming, indication that the destinations id (too?) full to perform the backup. This script takes about 6 minutes. The second script starts and the waits for about 12 hours. Maybe it starts grooming and can't groom out space enough to perform the actual backup? What happens at 12:10:49? The user reboots the computer? Or does indeed stop the backup? I would start looking at the (free) space on the destination.
  4. I don't understand if you will go back and forth between Mac and Windows, or if this was a one-time move.
  5. It is the metadata that makes the files look different to Retrospect. Some years ago a co-worker had a Windows computer with three hard drives: An XP boot drive, a Vista boot drive and a data drive. When booted into XP, all files of the XP disk and the data disk was backed up (as expected). When booted info Vista the entire data disk was backed up again, since the different Windows versions displayed a different set of metadata to Retrospect, making Retrospect to believe it was different files. When booted back into XP, (only) the files that had changed on the data drive since the last XP backup was backed up. Similar with the Vista backup: The files on the data drive that changed since the last Vista backup was backed up. Why do you want to backup your external drive from both Windows and Mac? I would have it always connected to a Windows computer, install the Retrospect Client on the computer and backup from your Mac running Retrospect. If that won't work for you, please elaborate on your setup, what you want to do and why you want to do just that.
  6. It would not make much sense in backing up a volume you can't restore. The OS (and/or Retrospect) can't write back any information, making the backup useless. There are no official documentation from Microsoft how NTFS really works. That's probably why Retrospect for Mac will not handle it. Do you really need it to be NTFS? I would recommend exFAT, which Windows and macOS handles just fine. Retrospect for mac and Retrospect for Windows handles it as well.
  7. That is correct, but NTFS is a native Windows file system. Try to backup a Mac drive on the Windows version.
  8. Strange. Although macOS can't write to an NTFS volume, it can read it. So Retrospect should be able to handle it perfectly well. I think you might want to open a support case. https://www.retrospect.com/en/support/edition
  9. How is "Mac Studio" formatted? And what partition map does it have? (GUID or MBR or ...)
  10. The local drives should turn up in "Sources". I have a slightly older Retrospect and a slightly older macOS, but here is what it looks like here:
  11. Without storage groups you can backup one client to one destination at a time. Which means that with multiple destinations (backup sets), you can backup multiple clients simultaneously. That could make sense if you group your clients according to where they belong in the organisation. For instance, finance department computers use the finance backup set, production department computers use the production backup set and so on. Each department can then be backed up simultaneously as the departments. With storage groups you can have a large backup set for all computers and several clients can be backed up to that backup set simultaneously. Having a single, large, backup set may or may not be an advantage. Besides, version 12 is outdated by now. For instance, recent Windows 10 versions are not supported and not Windows 11. If you run older versions of Windows you may be fine with Retrospect 12, otherwise I would not trust it to restore without problems.
  12. The question is how the old .rdb-files got there. One theory is that you had a backup set with the same name that you deleted (forgot) in Retrospect, did NOT delete the .rdb-files and then created a new backup set with the name and storing the member files in the same location. Does that sound feasible? In that case it would have been better to recycle the backup set and Retrospect would have deleted the old files for you.
  13. Say what? 14.6 is four years old by now. How old is your OS? How old is your NAS firmware?
  14. That clearly looks like a bug. You should contact support: https://www.retrospect.com/en/support/phone
  15. Not sure what you mean by "import" as that is not a Retrospect operation, as far as I remember. You should select "Media Sets" in the list to the left and then "Rebuild".
  16. Oh, and 38 past backups seems like a lot. Maybe you should try (temporarily?) to keep (say) the last 10 backups?
  17. Retrospect creates backup files that are around 650MB in size. With performance-optimized grooming, they are all kept intact until all its contents can be groomed out. This often means that hardly any data is groomed out and that can be the source of your problem. With storage-optimized grooming these files are shrunk as old backups are removed from them, one by one.
  18. I see. Getting a RAID (or two) into the equation makes it more complicated. I have never used Retrospect with so much data. How many backups do you have stored on the 85 TB disk? How much data on the 50 TB source gets changed daily (or weekly)? What kind of files are they? Database files that gets updated by the minute? Or video files that "never" changes? What groom settings did you use when you groomed?
  19. Let's see here. You mean 50 GB on your source drive (not TB), right? Otherwise you must have a small stack of external disks to store 50 TB. As for your backup drive: I asked the size of the drive and 85 TB is a slightly larger stack of disks. And if you mean 85 GB? Well, you can't buy disks with that size. So what size is the disk really? Repairing the backup disk means fixing any errors in the disk directory. Think of it as the index of a book. If the index gets corrupted it would be difficult to find the page you are looking for. How to repair: https://support.apple.com/en-us/HT210898
  20. How much data are there on your source drive? How large is the backup drive? Have you repaired the backup drive with Apple's Disk utility? What version of Retrospect? What version of Mac OS? To see what has been backed up: Click on "Past Backups" and then on "Browse" for the backup in question. Click on the checkbox at lower left and then on the disclosure triangle to see what was backed up.
  21. It's been some years since I used proactive scripts, so things may have changed how they work. And I also may not remember everything correctly. Back then (I think) the time between backups was measured from the end of the last backup to the start of next, so I had to set that to 23 hours (instead of daily) to get the next backup of that source to start a little earlier "tomorrow" than it ran "today". Otherwise it may miss the active window. The active windows was set to normal business hours plus one hour at each end to cater for those who came a bit early and those who had been on the road and arrived late. Perhaps you should set up the proactive script to run between (say) 6 AM and 8 PM. That should be ample time for the backup to finish. Except, perhaps, with the exception of the very first backup for each backup set. As for why your backup terminates at midnight, I have no idea. It shouldn't do that. Perhaps you could share a screenshot or two of your script settings?
  22. How old are they and how much have you used them? Old hard drives are failures waiting to happen. (On the other hand, it's many years ago I had a drive fail on me, even after years of use. ) No. Most files nowadays are already compressed and can't be compressed more. It's just a waste of (CPU) time and energy. Anyway: With that kind of data, you should be fine using the setup you have proposed with 2 sets of 3 backup drives. They should be large enough. I would not use block level incremental backup. That's useful only for very big files where you change only parts of the files, such as database files. I would use Disk backup sets, not storage groups. You should probably run a Groom script every once in a while, to groom out old backups. (You don't HAVE to, as Retrospect will do that for you when the disk becomes full. BUT that will happen in the middle of a backup and according to Murphy's law it will happen when you are in a hurry to get the backup finished.) Hope this helps.
  23. How much data is there on E: X: and Y: respectively? As a rule of a thumb, you should allocate storage about twice the size of the DATA you want to backup. Instead of two sets of three backup disks, you may want to have two larger disks. Seagate has disks with 16 TB capacity as well as 8 TB for about 40% of the price for the 16 TB disk. With larger disks as backup disks, you need only two backup sets. That way you can use "grooming", a process that "grooms" out the oldest backups. That way you don't have to erase all data to start copying x TB of data from scratch.
×
×
  • Create New...