Researched recently with this result: many commercial backup solutions developers removed MacOS support.
Will solutions be considered with Apple to fix the problem? What are the backup solutions on MacOS that you recommend in the type of urbackup ?
With some hacking, it’s still possible to install the client (just decompress the files contained in the installer package and copy them manually, it’s quite easy).
So even if perfectible, I’d rather have the Mac client present and marked “community supported”. And I’ll be glad to post the workaround somewhere.
How about that Martin?
I’ve been using borgbackup and it’s associated borgmatic script to backup various platforms at work (Mac, Windows and Linux). It’s overall a more “hackable” solution with pros and cons compared to urbackup, but I also like it.
Another issue I’ve had (and fixed) with urbackup for Mac is that the installer sets up it’s var folder inside the application folder.
Given how apple handles authorizations, changing data inside the app folder voids the app’s authorizations to access the disk on every backup. The effects show when the daemon is relaunched (this happens at computer restart or sometimes after sleep).
The simple workaround is to move the var folder to /etc and symlink to it from its original location.
This would have been helpful
Sure. The hope is that someone takes over maintaining the macos client. The basic step, running https://github.com/uroni/urbackup_backend/blob/dev/create_osx_installer.sh shouldn’t be too hard.
Beyond fixing the issues, what would be nice:
- Checking if it has full disk access after installation and displaying a screen with instructions otherwise
- Somehow integrating with APFS snapshots
- Low priority: Finding out how APFS sparse files work and supporting those
Idk if the
/etc area ist the most approriate one. It probably has a better per-applications directory somewhere else (like AppData on Windows).
no solutions yet?
I believe it’s a hard path to take for UrBackup because it’s too platform specific, and it would require a substantial effort to maintain. I’d be better off skipping the “protected” folders of Mac OS (like /bin /sbin and a few others) because they are supposed to be handled by the OS install and update mechanisms (that’s why even Mac OS updates have to boot in a special mode to process those regions, then the Mac boots normally again).
The most important dirs to backup, I think, are /etc /Library and of course /Users. That won’t allow immediate restore of whole systems, but at least we don’t lose user data and configurations.
For Mac applications, the right place to store data is probably in /Library/Application Support/APPNAME/
If it’s user specific data for a given application that would be $HOME/Library/Application Support/APPNAME/
It’s not about system backups. In general, if you backup files without snapshots you have a chance that they are currently undergoing changes and are inconsistent (which makes those backups worthless). Think of the database file of you mail application for example.
If there is a command line tool to create APFS snapshots it’s as simple as creating a snapshot script such as this: https://github.com/uroni/urbackup_backend/blob/2.4.x/linux_snapshot/btrfs_create_filesystem_snapshot
tmutil localsnapshot ? Lots of useful stuff for creating and accessing snapshots enumerated here: https://derflounder.wordpress.com/2019/05/08/creating-managing-and-using-apple-file-system-snapshots-for-startup-drive-backups/
Yeah, this looks like it would work
Even snapshots don’t guarantee a consistent file, as they can happen anytime, right? The only way to a clean backup is to stop all processes which have write permissions on a file while the backup is happening, resulting in more or less downtime. Where applicable, database master/slave configuration is preferable to backups.
Well, if we use btrfs snapshots on linux, it makes sense to use APFS snapshots on Mac, so let’s go
In the worst case a snapshot is “crash consistent”, i.e. as if you pulled the power plug. Most applications are written such that their data files survive sudden power fails/blue screen etc., especially databases (But not if half of the data file is from time T1 and the other from a different time T2!!).
Additionally most snapshots also flush data from RAM to disk first (or include data cached in RAM in the snapshot).
Best case is Windows where applications can register to get backup events (VSS) and write data and say which files need to be backed up.
There are no solutions for installing the agent on the latest version mac?inst.log.zip (1.6 MB)
I managed to install the latest version by manually hacking inside the .pkg (extracting cpio archives, executing scripts etc). I don’t remember the details but it was quite straightforward (the “file” command is your friend).
After installation, don’t forget to move the “data” directory from inside the app folder to say /etc and symlink to it. Changes to the app folder void the app’s authorizations (to access files for instance).
I ran the command: pkgutil --expand thePackage.pkg /destination
and got four files: Distribution, Resources(2 html file), output.pkg, output2.pkg - no one cant execute
no legal methods yet?
Repeat the process with those 2 .pkg files, you’ll end up with items you can move manually to the correct places. 3 things are installed in the end : the application folder (in /Applications), the startup script for the daemon (in /Library/LaunchDaemons), and the startup script for the application (in /Library/Launch… (I forgot the name)).
If I get some spare time I may write a script to automate all that, but better not wait for it.
Payload -> Library:
what to copy and where?
Copy the org.urbackup.client.plist files in their right places (/Library/Launch…)
Copy the contents of the other payload in /Applications/UrBackup.app/Contents/… (have a look at how other applications are organized).