We back up servers.
We back up databases.
We back up laptops, virtual machines, configuration files, Kubernetes clusters, and probably a few things that really do not need their own backup strategy.
But what about the device we carry around every single day?
Our phones contain photos, documents, downloads, exported files, authenticator backups, recordings, project files, and countless other bits of data accumulated over the years.
And yet, for many people, the backup strategy for all of that data is essentially:
“I think Google is syncing it somewhere.”
That is not quite the same thing as having a backup.
So I built Resticopia.
Resticopia is an open-source Android application for creating and managing backups using Restic.
It brings a proper backup tool, with repositories, snapshots, encryption, scheduling, and retention, to Android without requiring you to manage everything from a terminal.
Synchronization is not a backup
This distinction is worth making first.
Cloud synchronization is extremely useful. I use it too.
But synchronization and backup solve different problems.
If you delete a synchronized file, that deletion may eventually be synchronized too. If something corrupts your data, the corrupted version can replace the good version. If you lose access to an account, your ability to access that data may disappear with it.
A backup gives you something different:
a historical copy of your data that you can restore later.
Ideally, backups also live independently from the device they protect.
Keeping a second copy of /Pictures somewhere else on the same phone is not particularly useful when the phone ends up at the bottom of a lake.
The same applies to hardware failure, accidental deletion, filesystem corruption, theft, or simply replacing a device.
The question is not really:
“Will I ever lose data?”
The better question is:
“When something disappears, how difficult will it be to get it back?”
The boring backup rule that actually works
A commonly used guideline is the 3-2-1 backup strategy:
- keep 3 copies of important data,
- on 2 different types of storage,
- with at least 1 copy somewhere else.
You do not have to follow that formula religiously.
The important idea is separation.
Your phone should not be the only place where irreplaceable data exists.
And your backup should not depend entirely on the continued existence of your phone either.
For example:
Android phone
|
+-- local data
|
+-- Resticopia
|
+-- encrypted Restic repository
|
+-- NAS
+-- S3-compatible storage
+-- Backblaze B2
+-- rest-server
+-- other storage via Rclone
Now losing the phone does not necessarily mean losing the data.
Why Restic?
I did not want to invent another backup format.
Restic already solves the difficult parts of backup very well.
It is designed around a few principles that I think a backup system should have: backups should be secure, efficient, verifiable, and easy enough that people actually run them.
Restic stores backups inside a repository.
Each backup creates a snapshot, giving you a view of your files at a particular moment in time.
It also encrypts repository contents, performs deduplication, and only needs to store new data instead of creating another complete copy of everything every time a backup runs.
That makes it very well suited to regular, automated backups.
There was just one problem.
Restic is primarily a command-line tool.
On a server, that is perfect.
On a phone, not so much.
Enter Resticopia
Resticopia provides an Android interface around Restic and Rclone.
Under the hood, it runs the native Linux tools in a custom PRoot environment on Android.
From the application, you can:
- create and configure Restic repositories,
- select directories to back up,
- run backups,
- browse snapshots,
- configure scheduled backups,
- define retention and cleanup policies,
- monitor backup progress through notifications,
- use local repositories,
- connect to S3, Backblaze B2, and REST repositories,
- and use Rclone for many additional storage providers.
The goal is not to hide Restic.
It is to make using Restic on a phone practical.
I still want the repository to be a normal Restic repository.
Resticopia is simply the tool that makes managing it from Android comfortable.
Set it and forget it, almost
One of the most important features of any backup solution is automation.
A backup procedure that relies on remembering to press a button every Sunday eventually becomes a backup procedure that has not run for six months.
Resticopia lets you schedule backups.
That changes the workflow from:
I should probably back up my phone.
to:
My phone was backed up last night.
That is a much better state to be in.
You can also configure retention policies so that keeping historical snapshots does not mean keeping every snapshot forever.
Automation does not mean backups should never be checked, though.
A scheduled job can fail.
Credentials can expire.
Storage can fill up.
Android can change permissions.
A backup that has not successfully completed for six months is not much better than no backup at all.
The ideal backup system therefore needs to be both automatic and observable.
Android makes this surprisingly complicated
Running a traditional backup tool on Android is more complicated than it sounds.
Desktop Linux normally gives applications fairly predictable filesystem access.
Android intentionally does not.
Its storage model has become increasingly restrictive over time, particularly around removable storage and application-specific directories.
A good example appeared almost immediately in the Resticopia issue tracker.
Someone wanted to create a Restic repository on an external USB or SD card.
Sounds simple:
- connect storage,
- give the application file permissions,
- create a repository,
- done.
Except Android had other ideas.
Even with “All files access” enabled, attempts to create the repository resulted in permission errors under locations such as /mnt/media_rw and /storage/....
The issue is still a useful illustration of something I discovered repeatedly while developing Resticopia:
making backup software is not only about implementing backup software.
You also have to work around the operating system’s storage model, background execution rules, permissions, power management, and increasingly isolated application environments.
Android is very good at reminding you that applications do not own the filesystem.
Issue #1 is here for anyone interested in the details:
Backup to external USB/SD Card, Resticopia #1
It is exactly the kind of problem that motivates me to keep improving the application.
A user should not have to understand Android mount points just because they want a second copy of their photos.
Local backups are useful, but do not stop there
Resticopia supports local repositories, and they can be useful.
For example, backing up to removable storage gives you a copy that can physically leave the phone.
But keeping a backup permanently attached to the same device has obvious limitations.
If both disappear together, the backup does not help much.
This is where Restic’s remote backends become particularly interesting.
You can keep your repository on infrastructure you control:
Phone
|
+--> Resticopia
|
+--> Restic repository
|
+--> your server / NAS / object storage
Or use an object-storage provider.
Or use Rclone to connect to another supported remote.
Resticopia does not try to decide where your data should live.
That is deliberate.
I want users to be able to choose their storage rather than making the application dependent on a specific cloud service.
Own the backup, not just the application
This is also why using Restic underneath matters to me.
I do not want your backup to become useless because one Android application disappears.
The important thing is the repository.
Your data is stored using Restic’s format and can be accessed with Restic independently of Resticopia.
That separation is important.
Applications come and go.
Phones definitely come and go.
Your backups should survive both.
A backup is only useful if you can restore it
There is one last point that is easy to overlook.
Creating backups is not the actual objective.
Restoring data is.
A backup that has never been tested is partly an assumption.
Every once in a while, pick a file from an older snapshot and restore it.
Check that you know where your repository password is stored.
Make sure the repository is reachable.
Make sure you actually understand the recovery process before you urgently need it.
Because the worst possible moment to learn how your backup system works is ten minutes after losing your data.
Try Resticopia
Resticopia is open source and still evolving.
You can find the application here:
The source code and issue tracker are available on GitHub:
github.com/dawiddyd/resticopia
It is also available through F-Droid.
If you find a bug, have an idea for improving the application, or discover another interesting Android storage edge case, open an issue.
Backup software gets better when it meets real devices, real storage, and real-world failure modes.
And if you do not use Resticopia, that is fine too.
Use Restic directly.
Use another backup application.
Use your NAS.
Use external storage.
Use a cloud provider.
Use several of them.
Just make sure that the only copy of something important is not sitting on a tiny device you carry around every day.
Because backups are boring.
Right up until the moment they become the most important thing you have.
Buy Me a Coffee
If you find Resticopia useful and want to support its development, you can buy me a coffee.
It helps me keep working on the app, fixing bugs, and adding new features.