# BBackupp: automated iOS backups from a Mac, with SFTP and S3 targets > BBackupp is a GPL-3.0 Swift app that schedules iOS device backups, tracks progress per file, and can push the result to local storage, SFTP or S3. Its author states plainly that it is bad for most users and that it does not restore. **Lakr233/BBackupp** — Automated iOS Backup Robot - Repository: https://github.com/Lakr233/BBackupp - Stars: 2,637 · Forks: 183 - Language: Swift - License: GPL-3.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/lakr233-bbackupp ## What BBackupp solves, and for whom The README opens with a blunt statement: the software meets the author's personal needs but is "pretty bad for most users." That is not modesty, it is a scope declaration. BBackupp targets someone who keeps one or more iOS devices on a desk, wants a backup to run on a schedule without plugging anything in, and wants the resulting data to land somewhere a server can read. The feature list matches that reader: one-time backups to local storage, scheduled backups, per-file progress monitoring, encryption, and destinations beyond the local disk, specifically SFTP and S3. It is the wrong tool for the ordinary iPhone owner. There is no restore path in the application. The README directs you to a separate project, MobileTransfer, if you want your data back on a device. Anyone looking for a backup browser to open an existing iTunes or Finder backup and pull photos out of it is in the wrong repository; the README does not describe that workflow at all. Two features narrow the audience further. Wireless backups with IP address support and the MuxProxy component exist for devices that are not reachable over mDNS, which the README frames as an environment for Tailscale or ZeroTier. And the App Store installer download feature suggests a user who wants installers on hand, not just device data. ## How the backup pipeline is put together The repository splits into an application target, BBackupp/, and a separate MobileBackup/ directory, alongside an Xcode workspace and project file. MobileBackup is where the backup logic lives, separate from the UI, which is a sensible boundary for a project whose author openly says he cannot maintain it: the part that talks to devices is not tangled into view code. The README describes the storage layer as snapshot based. Backups are written as snapshots rather than a single flat archive, which is what makes repeated scheduled runs practical, since the tool is not rewriting one monolithic file each time. Where those snapshots go is configurable: local storage, SFTP, S3 and, in the README's phrasing, "and more." Device discovery and connection are the other half. For wireless work the app needs a pair record, and BBackupp supports exporting a pair record from one machine and importing it on another, so a device can be registered without being physically attached. The README is careful here: not all pair records work with this, and it recommends doing at least one wired backup before exporting. The technical note explains why, stating that the EscrowBag, the device backup key, is transferred to the host at an unspecified time, and that the record only functions if it already contains that key. That is an honest description of a mechanism the author cannot fully control. MuxProxy handles the case where mDNS is unavailable. It lets the toolchain work with libusbmuxd over a tunnel, and the README points to a Copy Terminal Environment button under the Muxd menu for wiring other tools into the same setup. The performance caveat is explicit: with a standard Tailscale configuration, transferring device information takes about 15 seconds, and the README recommends a high-speed connection because a full backup over a slow link may not finish in reasonable time. ## Installing BBackupp with Homebrew and running a first backup The README gives two installation routes: Homebrew, or a download from the GitHub Releases page. Homebrew is the one with documented steps. It assumes Homebrew is already present; if it is not, the README includes the standard install script. ```bash /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ``` With Homebrew available, the package name is bbackupp. Note the lowercase spelling, which differs from the project name. ```bash brew install bbackupp ``` Building from source is a different path. The README states that you need the git submodules checked out and that brew must be installed, then adds a line that sets expectations: for anything else related to compiling, fix it yourself. The repository carries BBackupp.xcworkspace and BBackupp.xcodeproj, so an Xcode build is the intended route once submodules are in place. ```bash git clone https://github.com/Lakr233/BBackupp.git cd BBackupp git submodule update --init --recursive ``` For a first real backup, the README's guidance is to start wired. Connect the device, let BBackupp see it, and complete one backup over the cable. Then, if you want the device registered on another machine, use Import Pair Record under the Muxd menu, entering an IP address and verifying accessibility. The README's stated reason for the wired-first order is that the pair record needs the EscrowBag key, which is not guaranteed to be present otherwise. There is no documented command that performs the backup itself; the README describes the actions as menu items in the application. ## Where BBackupp breaks, and the cases it does not cover The largest limitation is stated by the author rather than discovered by a user: no recovery. If your phone dies and your only copy of its data is a BBackupp snapshot, you cannot restore it with BBackupp. You install MobileTransfer instead. That split means the backup tool and the restore tool are separate projects with separate states of maintenance, and a snapshot format that works today is only useful if the restore side keeps reading it. The pair record mechanism is the second soft spot. The README says not all pair records are compatible and recommends a wired backup first. That is a workaround, not a guarantee. If you are trying to register a device you cannot physically reach, the feature may simply not work for your device, and the README offers no diagnostic path beyond verifying the IP address is reachable. Wireless transfer speed is a real constraint. The README states that with a standard Tailscale configuration, transferring device information takes roughly 15 seconds, and warns that a complete backup over a slow link may not finish in a timely manner. For a device with a lot of data, the tunnel becomes the bottleneck, and the README explicitly declines responsibility for networking problems. The maintenance position deserves its own mention. The README says the author open-sourced the code because he could not provide ongoing maintenance, and that support or updates are unlikely in the future. The repository's last push was on 2026-05-18, so it is not abandoned, but the author's own statement should set your expectations about how a bug report will be handled. The disclaimer section, which lists consequences up to the Earth exploding, signals the same thing in a lighter register. ## BBackupp against iMazing and the Finder backup The obvious comparison is iMazing, which covers the full loop: back up an iPhone, browse the contents, and restore selected data. BBackupp deliberately covers only the first part and hands restore to MobileTransfer. If your requirement is "get my messages back onto a new phone this afternoon," iMazing is the shorter path, and BBackupp is not an alternative to it at all. The second comparison is the built-in path: Finder on macOS or iTunes on Windows, plus a scheduled backup setting. That route is free, already installed, and restores in place. What it does not do is write to SFTP or S3, run as a headless scheduled job with notifications, or track progress per file. BBackupp's feature list is aimed squarely at those gaps. If you only ever back up to the internal disk of the Mac the phone is plugged into, the built-in option covers you and BBackupp adds a dependency for nothing. A third point of difference is the notification layer. BBackupp supports Bark and a Telegram bot, sending messages at the start, the end, and on failure. That matters for unattended operation: a scheduled backup that silently stops running is worse than no schedule, and the README's alive checker, a simple GET request, exists for the same reason. Neither the built-in Finder backup nor iMazing offers a comparable hook for a self-hosted alerting setup. ## Licence, build cost and what maintenance looks like BBackupp is GPL-3.0. The README notes the licence is subject to change, which is worth reading as a statement about the project's direction rather than a promise. For an internal deployment, the practical question is whether you intend to distribute a modified build. GPL-3.0 carries obligations in that case, and the repository's LICENSE file is the document that governs, not this article. If you only run the Homebrew package or an unmodified release, the licence question is simpler. If you plan to fork the backup engine into a product, talk to someone qualified; the README does not offer guidance on this and the author's disclaimer explicitly disclaims liability. The upgrade cost is low if you stay on the Homebrew route, since brew handles the binary. It is higher if you build from source. The README lists the requirements as checked-out submodules and a working brew, and then says to fix anything else yourself. There is no documented CI pipeline for producing your own builds, though the repository does contain a .gitlab-ci.yml at the top level. Whether that file covers the full application build is not stated in the README. The maintenance cost is the part to weigh honestly. The last push was on 2026-05-18, and the most recent release listed is 2.14.74 from 2024-08-13. The author's statement that he cannot provide ongoing maintenance is the clearest signal in the repository. Treat the source as your support contract, and budget accordingly if the backup is load-bearing. ## Conclusion BBackupp fits an operator who already owns a Mac, wants scheduled iOS backups landing on SFTP or S3, and accepts that restore happens elsewhere through MobileTransfer. It does not fit anyone who wants a phone-to-desktop backup they can browse and restore in one tool, and the README's own statement says as much. Before adopting it, verify three things: that brew install bbackupp resolves on your machine, that your pair record exports and imports (the README warns not all records are compatible), and that your destination storage is reachable at the speed a full backup needs. The author has stated he cannot provide ongoing maintenance, so treat the source as the support channel. ## FAQ ### Can BBackupp restore an iPhone backup? No. The README states that it does not support recovery and directs users to MobileTransfer for restoring a device. ### How do I install BBackupp? The README documents Homebrew as the installation route, with the package name bbackupp, and also points to the GitHub Releases page for a direct download. ### What is the best iPhone backup explorer tool? BBackupp is not a backup explorer. Its README describes scheduled backups, per-file progress monitoring and storage to local disk, SFTP or S3, but no browsing or extraction of an existing backup. ### How do I back up my entire iPhone with BBackupp? The README recommends completing at least one wired backup first, then configuring a schedule; the app supports one-time backups to local storage as well as automated schedules. ### Does BBackupp work over Tailscale or ZeroTier? Yes, through MuxProxy, which the README describes as facilitating device discovery where mDNS is unavailable. It warns that a high-speed connection is recommended and that a standard Tailscale configuration takes about 15 seconds to transfer device information. ### Can I move a paired device from one Mac to another with BBackupp? The README documents transferable pair records and an Import Pair Record menu item, but warns that not all pair records are compatible and recommends a wired backup first so the record contains the EscrowBag key. ## Sources - [Issues](https://github.com/Lakr233/BBackupp/issues) - [Lakr233/BBackupp on GitHub](https://github.com/Lakr233/BBackupp) - [License: GPL-3.0](https://github.com/Lakr233/BBackupp/blob/main/LICENSE) - [README](https://github.com/Lakr233/BBackupp/blob/main/README.md) - [Releases](https://github.com/Lakr233/BBackupp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lakr233-bbackupp