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 urbackup_backend/create_osx_installer.sh at dev ¡ uroni/urbackup_backend ¡ GitHub 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: urbackup_backend/linux_snapshot/btrfs_create_filesystem_snapshot at 2.4.x ¡ uroni/urbackup_backend ¡ GitHub
Such as tmutil localsnapshot ? Lots of useful stuff for creating and accessing snapshots enumerated here: Creating, managing and using Apple File System snapshots for startup drive backups | Der Flounder
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.
1 Like
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.
im got.
folder output:
Bom(exec)
PackageInfo(exec)
Payload â Library:
LaunchAgents->org.urbackup.client.plist
LaunchDaemons->org.urbackup.client.plist
folder output2:
Bom(exec)
PackageInfo(exec)
Payload->Contens:
info.plist
MacOS->bin,etc,sbin,share,var,urbackupclientgui
Resources->upbackup.icns
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).