Based on my previous scripts and inspired by two blog posts that I stumbled upon I tackled the “backup all my apps, settings and data” problem for my Android devices again. The “new” solutions both use
rsync instead of
adb pull for file transfers. They both use ADB to start a rsync daemon on the device, forward its ports to localhost and run rsync against it from your host.
Simon’s solution assumes your phone has rsync already (e.g. because you run CyanogenMod) and can become root via
adb root . It clones all files from the phone (minus
/proc etc.). He also configures udev to start the backup automatically when the phone is plugged in.
pts solves the setup without necessarily becoming root. He also has a way of providing a rsync binary to phones that don’t have any (e.g. when running OxygenOS). He also has a few tricks on how to debug the rsync daemon setup on the phone.
I’ve tried to combine both methods. My approach doesn’t require adb or rsync to be run as root. It’ll use the the system’s rsync when available or temporarily upload and use a backup one extracted from Cyanogen OS (for my OnePlus One). Android won’t allow you to
chmod +x a file uploaded to
/sdcard , but in
/data/local/tmp it works. 😀
The scripts will currently only backup and restore all of your
/sdcard directory. Assuming you’re also using something like Titanium Backup you’ll be able to backup and restore all your apps, settings and data. To reduce the amount of data to copy it uses rsync filters to exclude caches and other files that you definitely don’t want synced (
.DS_Store files anyone?).
At the moment there’s one caveat: I had to disable restoring modification times (i.e. use
--no-times ) because of an obnoxious error (they will be backuped fine, only restoring is the problem): 😒
mkstemp “…” (in root) failed: Operation not permitted (1)
If you’re an Ansible user and encounter the following error:
unix_listener:"..."too longforUnix domain socket
you need to set the control_path option in your ansible.cfg file to tell SSH to use shorter path names for the control socket. You should have a look at the ssh_config(5) man page (under
ControlPath) for a list of possible substitutions.
In the company I work for we’re using RabbitMQ to offload non-timecritical processing of tasks. To be able to recover in case RabbitMQ goes down our queues are durable and all our messages are marked as persistent. We generally have a very low number of messages in flight at any moment in time. There’s just one queue with a decent amount of them: the “failed messages” dump.
It so happens that after a botched update to the most recent version of RabbitMQ (3.5.3 at the time) our admins had to nuke the server and install it from scratch. They had made a backup of RabbitMQ’s Mnesia database and I was tasked to recover the messages from it.
This is the story of how I did it.
Since our RabbitMQ was configured to persist all the messages this should be generally possible. Surely I wouldn’t be the first one to attempt this. 😐
Looking through the Internet it seems there’s no way of ex/importing a node’s configuration if it’s not running. I couldn’t find any documentation on how to import a Mnesia backup into a new node or extract data from it into a usable form. 😞
My idea was to setup a virtual machine (running DebianWheezy) with RabbitMQ and then to somehow make it read/recover and run the broken server’s database.
In the following you’ll see the following placeholders:
Now what? Why don’t I try to give it the Mnesia files piece by piece again?
rabbit_* files in again and fix their permissions
All our queues were back and all their configuration seemed OK as well. But we still didn’t have our messages back yet.
So I tried to copy more and more files over from the backup repeating the above steps. I finally reached my goal after copying
recovery.dets. Fixing their permissions and starting RabbitMQ it had all the queues restored with all the messages in them. 😂
Now I could use ordinary methods to extract all the messages. Dumping all the messages and examining them they looked OK. Publishing the recovered messages to the new server I was pretty euphoric. 😁