PBS Backup a MacBook?

[Kavendish]

+1 for a mac client. Would really come in handy.

 

[aDZ5OfZ8l8GU8lSlLhBD]

+1 mac client

 

[stuartbh]

I guess really a "mac client" is not what is needed so much as an option to easily provision or provide for the automatic provisioning of an SMB share. If that were the case, then Time Machine could simply perform its regular backups and point itself at the PBS, no?

That would seem a less invasive and support needy mechanism for allowing PBS to handle backing up Mac clients.

Stuart

 

[Einar Stenberg]

I suggest this,
Create a VM with a fileshare on it that you can run your timemachine backups to,
then backup that vm with PBS

 

[Einar Stenberg]

I guess really a "mac client" is not what is needed so much as an option to easily provision or provide for the automatic provisioning of an SMB share. If that were the case, then Time Machine could simply perform its regular backups and point itself at the PBS, no?

That would seem a less invasive and support needy mechanism for allowing PBS to handle backing up Mac clients.

Stuart

my docker image for proxmoxbackup client can backup SMB shares as schedueled tasks, try it out if you need to do that.

https://github.com/OvrAp3x/ProxmoxBackupClientDocker

 

[stuartbh]

Everyone,

Let me first start out by saying that I am quite happy with the backup software that macOS comes with, time machine. That said, there would be some level of convenience with respect to being able to do a back up to PBS directly from macOS. However, right now I run a TrueNAS file server and that is the target for all my PBS backups as well as my macOS backups.

The server that I run TrueNAS SCALE on has the one singular purpose of being a file server. Even with ZFS wanting a lot of RAM it is using only 20GB or just under 1/2 of the 48GB in the server.


Stuart

 

[Andbur Support Technique]

+1 for Mac

 

[Saline5168]

a Mac/Windows port is a lot more work than just "recompiling" for that platform - those OS use different APIs for file access and attributes, locking, .., and use different file systems by default. given that we still have a lot of other plans for PBS as well, it's not super high on the TODO list (the cost/benefit ratio isn't there yet).

@Tmanok:

On the topic of file systems, with APFS, snapshots are a native feature in the file system, so the solution might be made a lot easier. Additionally, Timemachine has been designed to make use of these snapshots so perhaps it could be leveraged with the MacOS client? Might be a good idea to restrict PBS Client to versions of MacOS only using APFS for that reason as the older HFS+ does not have those snapshot capabilities to the best of my knowledge. Another thought, as Timemachine might be a bit restrictive, you may find that it is too limited for your purposes.

As @Tmanok mentioned, it is very straightforward to do backups on macos using the apfs localsnapshot facility, which stores all the file-level content within a "sparsebundle" (virtual disk-like) "file" which then can be stored/represented straightforwardly on linux filesystems. Many of us host these sparsebundles on samba fileservers configured to present themselves as Apple TimeMachine devices. It would be much better not to need to run a separate server for the purpose, but rather to be able to backup directly from the device.

Here's an example of leveraging the localsnapshot capability for doing borg backups: https://gist.github.com/QuantumGhost/1aae8eb8527c9d522fe2a57f214f6ee5

Now that nixpkgs has proxmox-backup-client packaged, presumably anyone with Nix installed might be able to leverage that from a Mac. I haven't tested it yet, built hope to do so soon. Assuming that works, perhaps we can validate definitively whether all works with nothing more than a darwin build.

 

[max]

TL;DR

+1 for macOS client

a Mac/Windows port is a lot more work than just "recompiling" for that platform - those OS use different APIs for file access and attributes, locking, .., and use different file systems by default. given that we still have a lot of other plans for PBS as well, it's not super high on the TODO list (the cost/benefit ratio isn't there yet).

On the topic of file systems, with APFS, snapshots are a native feature in the file system, so the solution might be made a lot easier. Additionally, Timemachine has been designed to make use of these snapshots so perhaps it could be leveraged with the MacOS client? Might be a good idea to restrict PBS Client to versions of MacOS only using APFS for that reason as the older HFS+ does not have those snapshot capabilities to the best of my knowledge. Another thought, as Timemachine might be a bit restrictive, you may find that it is too limited for your purposes.

On my previous Linux workstation I wrote myself some systems services and timers, that leverage btrfs snapshots done by snapper.
While the backup client works quite well by itself, that was my way to go because otherwise the client complained about some files, specially opened ones.

Now that I'm on macOS, I'd really appreciate some solution that would be a little less of a hack on my side.

 

[soupdiver]

Another +1

 

[jensie]

another +1

 

[swesource]

+1

 

[Zappy]

there is windows client alpha rising... mac user feel alone

 

[dean_za]

+1 for mac client

 

[Tmanok]

I guess really a "mac client" is not what is needed so much as an option to easily provision or provide for the automatic provisioning of an SMB share. If that were the case, then Time Machine could simply perform its regular backups and point itself at the PBS, no?

That would seem a less invasive and support needy mechanism for allowing PBS to handle backing up Mac clients.

Stuart

Look, you can do that, but in my experience over the last two decades of backing up using TimeMachine, remote backups become corrupted and this is still an unresolved issue in 2024. Additionally, you will need to configure your SMBv3 very carefully if you want any support from Apple to resolve issues related to remote TimeMachine configurations [1].

At this point, some of my clients who have IT departments are forced to regularly verify backups manually for their fleets (100+ Macs) but most of them (especially those who I have decision making power in) use an open source 3rd party software. While 3rd party software may work and receive support from the communities or companies performing the backups, I do not believe they are superior to Proxmox Backup Server by most metrics- let alone the fact that they are not centrally archived under one system nor able to be synchronized off-site seamlessly. By the way, those who use TimeMachine do not "allow" their staff to store important corporate information locally on the Macintoshes because of this situation, unless they are using a 3rd party backup solution. It's sad because APFS is a great leap in technology from HFS+, so Macintoshes should be more reliable than ever, but only having a single copy of data is the same as having 0 copies of that data in risk management as we know...

If you decide to correctly configure a VM with the required SMBv3 attributes for TimeMachine, still consider backing it up with Proxmox Backup Server, as you will ocassionally need to restore the VM's repository as TimeMachine is an unreliable backup solution- to take it a step further, many times you need to completely delete the repository and form a new backup over again because TimeMachine fails to take an old (valid) backup and combine it with an up to date snapshot of the system. I don't know why it's broken like this, but the error has been ongoing since AFP became deprecated years and years ago. Apple doesn't care about or like servers, they'd rather you pay them to use their SaaS Cloud (iCloud) for everything server related.

Put simply, TimeMachine is inferior to Proxmox Backup Server by a mile, and I hold true on the need for a MacOS client.

1. https://developer.apple.com/library.../NetworkingInternetWeb/Time_Machine_SMB_Spec/


Tmanok

 

[foux]

Definitely +1 for a mac client. Timemachine is bloated, slow, and breaks every so often on SMB share, it is just a nightmare. Can't wait for pbs client on mac

 

[michabbs]

+1 for Mac.

(Actually Mac client should be way easier to release than Windows client. MacOS is BSD Unix derivative, and client for Linux, which is also Unix-like system, already exists...)

 

[rswift]

i too would welcome a mac client... ahead of that being a thing, i've quickly solved the problem with Docker, i have no doubt there are far more elegant ways to do this (and certainly slimmer, the image is about 120MB), i'm not very experienced with Docker, but it works fine...

FROM debian:bookworm-slim

RUN apt update --yes && apt full-upgrade --yes && apt install --yes wget && \
    echo "deb http://download.proxmox.com/debian/pbs-client bookworm main" >> /etc/apt/sources.list.d/pbs-client.list && \
    wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg && \
    apt update --yes && \
    apt install --yes proxmox-backup-client && apt autoremove --yes

ENTRYPOINT [ "proxmox-backup-client" ]

Tweak to suit: docker build --tag pbs:latest .

Docker then needs a few things set up:

• set the hostname so PBS doesn't take the container ID (which will change every time)
• remove the container when the task completes (--rm)
• map the local mac file system to the container somewhere
• consider any exclusions (such as ~/Library if backing up a home directory as shown below)
• consider using shell variables for consistency (i.e. read -s PASSWORD to securely read in the PBS password value)
• if you change the tag when building, make sure that's correct when running
• the single quote is needed for the repository because of the !
• i set crypt off to keep it simple

read -s PASSWORD
MAC_HOST_PATH=/your/desired/path
CONTAINER_PATH=/container/path
HOSTNAME=${HOST}
PXAR_LABEL=whatever
REPOSITORY='user@realm!api@host:datastore'
FINGERPRINT=pbs:instance:finger:print

docker run --rm --hostname ${HOSTNAME} --name PBS --volume ${MAC_HOST_PATH}:${CONTAINER_PATH} --env PBS_PASSWORD=${PASSWORD} --env PBS_REPOSITORY=${REPOSITORY} --env PBS_FINGERPRINT=${FINGERPRINT} pbs:latest backup --backup-type host --crypt-mode none ${PXAR_LABEL}.pxar:${CONTAINER_PATH} --repository ${REPOSITORY} --exclude Library

Lots could be done better, use of files for the environment fields, put the fingerprint somewhere more meaningful etc. but this works for my immediate needs... pending the arrival of a proper macOS PBS client that can be brew installed

Hope this is mildly useful, and apologies for any tyops as i've transcribed my nonsense into this..

 

[soupdiver]

Now that nixpkgs has proxmox-backup-client packaged, presumably anyone with Nix installed might be able to leverage that from a Mac. I haven't tested it yet, built hope to do so soon. Assuming that works, perhaps we can validate definitively whether all works with nothing more than a darwin build.

Not yet so easily. Just tried it but it's not avaiilable for darwin atm

error: Package ‘proxmox-backup-client-3.2.2’ in /nix/store/65xpqkz92d9j7k5ric4z8lzhiigxsfbg-source/pkgs/applications/backup/proxmox-backup-client/default.nix:149 is not available on the requested hostPlatform:
         hostPlatform.config = "aarch64-apple-darwin"
         package.meta.platforms = [
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "loongarch64-linux"
           "m68k-linux"
           "microblaze-linux"
           "microblazeel-linux"
           "mips-linux"
           "mips64-linux"
           "mips64el-linux"
           "mipsel-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
           "x86_64-linux"
         ]