The digital landscape is defined by a handful of dominant search platforms, each acting as a gatekeeper to information. For too long, users have been forced to accept a business model built on data harvesting and algorithmic suggestion rather than truthful information retrieval. Degoog, the open-source search aggregator, is here to change that.
The News: Degoog’s First Stable Release
Degoog has finally reached its first stable version. This maturity is a direct result of the work by fccview and the dedicated community contributors overseeing the project at degoog-org/degoog. This release transforms Degoog from an ambitious project into a reliable, production ready utility.
What is Degoog?
Degoog is a meta search engine, a tool you self host, designed to operate outside the control of any single corporation. Instead of relying on one monolithic search provider, Degoog simultaneously sends the same query to multiple real search engines: Google, Brave, DuckDuckGo, and others. It then collects, cross references, and intelligently aggregates all the responses into one unified, clutter free interface.
Liberation from the Aggregator Trap
The core value of Degoog is its commitment to user sovereignty.
Privacy Guarantee: By running Degoog on your own hardware, you are in control. The platform adheres to a zero logging policy, ensuring that your searches do not become personal data points for tracking or profiling.
Comprehensive Sourcing: No longer are you stuck with the curated, narrow view of a single engine. Degoog’s parallel querying capability ensures maximum result diversity.
Uncluttered Experience: The results are presented cleanly, free of aggressive sponsored links, AI overviews that may contain inaccuracies, or attempts to funnel you into specific platforms.
A Search Experience That Adapts to You
Degoog is far more than a simple results aggregator. Its modular architecture empowers users to build a search engine perfectly tailored to their workflow.
The entire system is open for extension. Users can integrate custom search engines, “bang” commands, or powerful “slot” plugins. These tools allow you to customize the search experience, perhaps routing queries directly to specific industry forums or Github repositories.
Degoog is a powerful example of open source technology solving real world problems. It is a tool that empowers the individual, offering a decentralized, private, and reliable alternative in an increasingly surveilled digital world.
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:
