OK, for that ONE time only, SD could not make bootable backups. I honestly do not remember that “disaster”, and in fact from what I remember, made the bootable backups anyway. But as they say, it’s water under the bridge, Apple FINALLY got their act together, and I’m sure David had a significant influence on that.
In any event, bootable reliable backups via SD have been “alive and well”.
I don’t think there’s anything to “get” here, David. I made a decision to not keep versions via snapshots. It’s not like I couldn’t: this isn’t hard. I decided not to.
Why? Well, a few reasons:
I want to encourage people to use multiple backup methods, not just me. One, in my opinion, should be Time Machine, which is far better than it used to be and—and this is important—Apple will not help you if you’re using a 3rd party backup program. If you end up needing Apple to assist, for whatever reason, having Time Machine is useful.
Time Machine uses APFS features unavailable to 3rd party developers that make versions faster, better, and more reliable.
The OS manages Time Machine, automatically, transparently, and well. A user doesn’t have to worry about any 3rd party special snapshots…it’s all right there.
The Time Machine UI, built right into Finder, for retrieving versions is simple, and right there.
Should Apple restrict these things further in the future, the user is in a better place having something that Apple has written—a first party solution—as an option…
Allowing Time Machine to focus on what it does best allows me to focus on what I do best.
I don’t think that’s bad logic. It doesn’t cost the user any more. And it gives them both additional coverage and versions in a way that’s specifically and explicitly supported by the platform they’re on.
I purchased SuperDuper 4 today using my v3 upgrade discount (Thanks!) and installed it.
Because the interface is different I spent some time exploring it. I think the Preview is a nice feature and used it to see what would be updated.
I use three different backup/archive/clone strategies: Time Machine, SuperDuper, and Carbon Copy Cloner. I use each of them in a different way:
Time Machine runs once/day and I use a lot of exclusions–so I cannot do a full restore from a snapshot using TM.
SuperDuper runs once/week and does a Smart Update. It is a bootable clone.
CCC runs on demand and only copies /Users but also saves versions.
I’m just resuming using SD! in version 4 after some years not using it, so read most of the manual. It is quite extensive so my head is still swimming from the volume of information, but maybe this section on scheduling might clarify?
It could be you’re right, the backups just wait til it’s unlocked, but now I’m confused…
This was true in SuperDuper! Classic, too. The lock in the main window has to be unlocked for schedules, scripting, etc to work…
The deal is, you need to unlock for schedulels to run, as well as things to be able to be run by Shortcuts. It’s an authorization-to-run-without-clicking-copy-now lock.
I’m not quite sure wha you mean by “in a NAS setup” in this situation.
Certainly, you can back up to an NAS: you can copy things like your Documents or Pictures or Music directly to it, or, if you’re trying to do a full backup, copy to an image stored on the NAS.
I’m running my first clone with SuperDuper! 4. Two things I’m missing so far:
The documentation says that you know it is doing Turbo Smart Update by an icon that appears somewhere. Where? Is there an example image of what that looks like?
I can’t find where to view the log of what it is doing while the copy job is running. I don’t see anything in the interface. The documentation says the logs are in /Library/Logs/SuperDuper 4 but all I see is scheduler.log.
It says the copy job is predicted to take over 3 days! Yes, backing up to this drive is slow, but not that slow.
Hi, Michael. Turbo will appear in the job, above the time estimate. It will only happen in the 2nd copy (or later) for the same job. (Don’t use one job foor lots of different drive copies - use a job per drive pair copy.)
You conscsiously can’t view the log during a copy. If you really want to be overwhelmed with stuff, you can use log show, but I advise against it. You can expand the various sections to get more info.
We saturate the I/O bus, basically, when copying: it’s not going to go faster. Estimates are just that, though, based on current conditions, etc. It’s like a poll: a snapshot in time, biased a bit by knowledge of what’s happened so far…
I don’t know what SD! is doing, but estimates like this are usually something like:
Compute the data-rate so far. That would be total bytes copied divided by total time elapsed.
Or perhaps based on a running average over the last several minutes
Take the remaining amount of data and divide it by that rate to get an estimate of the remaining time.
But this is never going to be perfectly accurate. Some things that will affect it:
The data rate may vary during the backup. Some things that can affect it:
Other software doing things consuming CPU and I/O bandwidth. Especially if you’re backing up to a device that’s connected via a hub. And computers sometimes use internal hubs, where two or more ports may share bandwidth.
SSD wear-leveling and garbage collection. Even if the device doesn’t grind to a halt (e.g., if garbage collection must be performed in order to make free blocks available), various SSD controller background activities can affect throughput.
HDDs often run faster for data written to the edges of the platters vs. the center.
If you backup to a network device, network issues can have a massive impact on throughput.
Some data copies faster than others.
A directory full of very small files will be slower than a single large file consuming the same amount of space.
A sparse file will appear larger than the cumulative size of its storage blocks. But software that supports sparse files (as any backup app should), will only copy the blocks that are actually used.
There are housekeeping activities that happen before, after, and possibly during the actual file copying, which often don’t figure into estimates, including:
Time to create snapshots at the beginning
Time to delete snapshots according to retention policy
Time to write logs.
And if a backup app supports removable media, there can be other housekeeping activities, including:
Time to eject media at the end of its capacity
Waiting time for a user to insert media
Time to finalize optical media at the end of each disc.
If you click on a source that you have no copy jobs for, you get a page with suggested starter templates. But once you have created one copy job for that source, I don’t see how to get the same suggestions for creating a second job.
I looks like once you have one job, you’re on your own to figure out how to create any others.
SD4 can appear to get stuck: nothing changing at all on the copy job interface.
If you expand the Copying files step, you can see the path of the last file copied. That’s not what is currently checking. To see that, you can use Activity Monitor, CPU tab, process sdcopy. Do (i) on this process, then look at Open Files and Ports.
The source and destination files will be listed as open files. The source is on a snapshot, the destination is directly to the mounted volume.
Now if Dave says that the open file and the file shown in the Copying files section should be the same, then there’s something wrong. What I’m seeing is Copying files = /LIbrary/Developer/CoreSimulator/Images/images.plist (a really small file), but the open file is in /LIbrary/Developer/CommandLineTools/SDKs/MacOSX26.2.sdk/System/Library/Private/Frameworks.
No, it definitely does not do that as far as I know. If you’re seeing it, please send a support email with evidence, and, hopefully, a way to reproduce the problem.