Tocho: sovereign personal storage, encrypted and replicated across two locations

1. Introduction

Tocho is a personal project maintained by Ismael Ripoll and me, Raúl, with the goal of having a mass storage system that is reasonably reliable, encrypted and replicated across two different physical locations.

The initial idea was simple: each of us would have a Raspberry Pi with a 16 TB SATA hard drive. Each drive would store our own data and, at the same time, an encrypted copy of the other person's data. This way, each of us would have an off-site replica in another house.

Over time, the project has evolved. It is no longer just "a home NAS with a remote copy", but a personal infrastructure that combines:

• mass storage;
• cross-copies;
• encryption;
• native access from Linux;
• monitoring;
• protection against hardware failures;
• partial protection against ransomware;
• versioned backups with Borg;
• and a clear philosophy of technical sovereignty.

It is not an enterprise system, nor does it aim to replace a professional infrastructure. But it does provide a very significant improvement over having a single local copy, or worse still, having no systematic backup strategy at all.

2. Motivation

The main motivation is very practical: personal data takes up more and more space and does not always fit well with commercial cloud services. Photos, videos, repositories, documents, disk images, machine backups, personal projects and historical files can easily add up to several terabytes.

Commercial services solve many problems very well, but they also impose limitations:

• recurring monthly cost;
• dependence on a provider;
• uneven integration with Linux;
• lack of real control over protocols and automation;
• space limits;
• changing policies;
• and often an interface designed more for general users than for technical workflows.

Tocho stems from a different idea: if we have enough technical knowledge, we can build our own infrastructure, understand it, repair it and adapt it to our needs.

That said, one of the lessons of the project is precisely that this is not free. Even if you don't pay a monthly fee, you have to pay for drives, adapters, power, cooling, administration time, testing, monitoring and maintenance. The commercial cloud can seem expensive until you add up everything that operating a minimally reliable infrastructure yourself entails.

3. Project goals

The main goals of Tocho are:

1. Have plenty of storage space at an affordable cost.
2. Maintain a remote replica of important data.
3. Protect the confidentiality of the data hosted on the other person's server.
4. Reduce the risk of loss due to hardware failures, theft, fire or other local incidents.
5. Use standard Linux tools.
6. Allow native access to files, without depending on a proprietary application.
7. Make versioned and deduplicated backups.
8. Reduce the risk that ransomware or human error destroys all copies.
9. Keep the system understandable and repairable by both administrators.

The philosophy is that reliability does not depend solely on buying expensive hardware, but on combining good practices: replicas, encryption, monitoring, periodic checks, separation of privileges and a real ability to restore.

4. General architecture

Each participant has a similar setup:

• a Raspberry Pi acting as a server;
• a 16 TB SATA hard drive;
• a USB-SATA adapter compatible with large drives;
• a dedicated power supply for the drive;
• a physical case or rack;
• ventilation;
• SSH access with public keys;
• local file exporting, in my case also via NFS;
• encrypted spaces;
• and scheduled backup and verification tasks.

The conceptual scheme is this:

Figura 1

Each server has a dual function:

• main server for local data;
• remote destination for the other person's encrypted copy.

5. Cross-replica model

The basic replica model is deliberately simple. Data is copied periodically, usually overnight, using rsync.

In the usual case:

1. The local server holds the main data.
2. Before the copy, the drive's health is checked.
3. If the drive appears to be in good condition, synchronization begins.
4. The other person's data is stored encrypted.
5. The physical owner of the remote server cannot read the actual content.

Figura 2

It is also possible to force a manual synchronization after copying a lot of data. This reduces the risk window between the moment a new piece of data appears on the local server and the moment it is replicated remotely.

rsync makes it easy to limit the bandwidth (--bwlimit), but in practice we don't: each node has 1 Gbps and the copies run at night, so we have never noticed any performance loss, either on the home network or on the link between the two houses. If this ever changed, enabling the limit would be trivial.

6. RPO: how much data we can lose

In its current state, the system has an RPO of approximately one day for data that is only synchronized overnight.

RPO stands for Recovery Point Objective: the maximum span of data that is assumed could be lost in a disaster. If the copy is made every night, the usual maximum loss is whatever has been modified since the last successful copy.

In practice:

• if the nightly copy went well, I can lose at most the data from the same day;
• if I manually run a synchronization after copying a lot of data, I reduce that window;
• if the copy fails and I don't detect it, the real RPO gets worse.

This means monitoring is not a secondary detail. It is not enough to "have backups": you need to know that the latest copies have completed correctly.

7. Encryption with GoCryptFS

An essential point of the project is that each participant hosts the other's data, but must not be able to read it.

For this reason, part of the remote data is stored encrypted with GoCryptFS. This system allows having an encrypted representation of the files on disk, while the owner can mount them transparently when they need to access them.

This provides several advantages:

• the drive can be removed, replaced or destroyed without exposing the data;
• the physical owner of the server cannot inspect the actual content of the other person's copy;
• the copy can be made with standard tools, because in the end normal encrypted files are copied;
• mounting can be done locally on the Raspberry Pi or remotely from another computer.

Figura 3

In practice, it is useful to be able to do the mounting from a more powerful PC. The Raspberry Pi is an efficient machine, but encryption can load the CPU. If the process uses few threads or the copy is intensive, offloading part of the cryptographic work to a more powerful computer can improve performance.

8. NAS, but not just a NAS

Part of Tocho works as a NAS: a file server accessible from the local network. In my case, I can mount the files via NFS and work with them naturally from Linux.

This is very convenient, but it also introduces a risk: if my PC has full access to the file system, a mistake of mine, a faulty script or ransomware could modify or delete data directly.

For this reason it is important to distinguish two functions:

1. Working NAS, designed for convenient access to files.
2. Backup system, designed to keep versions and withstand errors or attacks.

A NAS is not automatically a backup. If it is permanently mounted with write permissions, it is part of the same risk surface as the PC.

9. Borg backups: deduplication, encryption and versions

To strengthen the backup side, I have started using BorgBackup. Borg is a backup tool with deduplication, compression and authenticated encryption. It is designed to make efficient backups, because after the first one it only needs to store the blocks that have changed.

This part is especially important because it introduces a conceptual difference compared to the classic use of a NAS.

With NFS, I work directly on visible files. With Borg, the client computers create versioned backup archives inside a repository. This allows keeping many versions without linearly multiplying the space used.

Borg provides three very valuable properties:

• encryption;
• deduplication;
• logical snapshots.

This makes it much more suitable for historical backup than a simple replica with rsync.

10. SSH keys restricted per computer

Each computer that makes backups to the server has its own SSH key, created specifically for that purpose.

These keys should not grant general access to the server, nor allow opening an interactive shell, nor administering the system. The idea is that each key only allows running the service needed to add backups to the corresponding Borg repository.

Borg supports the use of borg serve with forced commands via SSH, which is precisely the right pattern for this kind of configuration.

Specifically, this is achieved by restricting each key to a specific command within the authorized_keys file. If you prepend command="<authorized command>" before the public key, the server will only run that command when someone connects with the key, even if the client tries to launch a different one. This way, a key meant for making backups cannot open an interactive shell, traverse the file system or delete data arbitrarily. It is a key piece for reducing the risk of ransomware and other attack scenarios.

The scheme is roughly this:

Figura 4

This greatly reduces the risk in case a laptop, a PC or another client machine is compromised. If an attacker obtains the key from that machine, they should not be able to freely access the server or delete anything they want.

11. Append-only mode and defense against ransomware

One of the recent motivations of the project is to improve protection against ransomware.

The problem with a traditional NAS is that, if the files are mounted with write permissions from the main PC, ransomware could also encrypt or destroy the NAS data. In that case, the NAS would stop being a real backup and become a vulnerable extension of the computer itself.

To reduce this risk, Borg repositories can be configured in append-only mode. The Borg documentation explains that this mode is useful when a client machine makes remote backups to a server with borg serve, because a compromised client machine cannot permanently delete the server's copies.

The separation is key:

• clients can add copies;
• clients should not be able to destroy the history;
• pruning old versions must be a separate operation;
• an attack from a client computer should not be able to delete all good copies.

This does not eliminate all risks. An attacker could add bad or encrypted copies, and the problem would have to be detected before performing a destructive prune. But it is a very significant improvement over having an NFS directory permanently mounted with full access.

12. Separation between live data and backups

A future idea is to reduce the use of the server as a store of directly editable files and increasingly turn it into a store of Borg backups.

This means distinguishing between:

1. Live data, which can be opened, edited, moved or deleted from the normal PC.
2. Backups, which are only added to the repository and are not directly modifiable by the usual user account.

This separation is very healthy. Live data can be on local drives, for example on a 4 TB drive or an internal 2 TB drive. The Tocho server, on the other hand, can be dedicated mainly to storing encrypted and deduplicated Borg versions.

The goal is to move from this model:

Figura 5

to this other one:

Figura 6

If the user's normal account makes a mistake, runs an overly broad rm or gets compromised, it should not have direct access to destroy all the historical copies.

13. Incremental backups and partial synchronization

An open question is whether incremental backups can be made without having to traverse the entire file tree each time.

With rsync, the normal model is to compare source and destination to decide what has changed. This is robust, but can be costly if there are a great many files.

There are several possible strategies:

• launching manual synchronizations of specific folders after important changes;
• making Borg backups of the truly important datasets;
• using lists of recently modified files with find, although this is more fragile;
• better separating data by frequency of change: cold files, active data and critical copies;
• considering systems with native snapshots if Btrfs or ZFS is used in the future.

In general, for versioned backup, Borg is more suitable than a simple replica with rsync. For replicating a browsable file tree, rsync remains very simple and practical.

14. Native access from Linux and sovereignty over files

One of the most important advantages of Tocho is that it lets me work with my files natively on Linux.

Unlike some commercial cloud services, the system does not force me to go through a web interface, a proprietary application or someone else's integration layer. I can mount file systems with standard tools, access them with NFS, SSHFS, GoCryptFS or Borg, automate tasks with scripts and decide exactly how I want to organize the data.

This has enormous practical value. For a Linux user, the file system is not just a place to drop documents: it is a universal interface. The same tools I use to program, index, search, compare, version or transform data can operate directly on my files.

Google Drive is a good counterexample. Despite being a very popular service, Google does not offer a complete official Google Drive client for Linux. In fact, there is a community-maintained page, How long since Google said a Google Drive Linux client is coming?, which counts the time elapsed since April 24, 2012, when Google hinted that Linux support would arrive with the message "hang tight".

This absence forces Linux users to rely on unofficial tools or partial solutions. Some work very well, such as rclone, but they are still alternative layers around a service that is not primarily designed for my workflow.

With Tocho, on the other hand, the situation is the opposite: I control the server, the protocol, the file system, the encryption, the permissions and the automation. I do not depend on a company deciding whether Linux deserves first-class integration or not.

This is a concrete form of technical sovereignty: not just owning the data, but being able to decide how it is accessed.

15. What we still don't have: native photo management

That said, this sovereignty is still not complete in every area.

One outstanding point is photo management. Commercial services have solved the user experience side very well: automatic upload from the phone, shared albums, thumbnails, timeline, duplicate detection, easy sharing and convenient access from any device.

Tocho still does not offer its own alternative to that. It can store photos as files, naturally, but it does not yet provide an experience comparable to Google Photos, iCloud Photos or similar services.

An interesting future step would be to deploy our own photography solution, capable of:

• receiving automatic copies from the phone;
• generating thumbnails;
• organizing albums;
• sharing photos and albums easily with friends and family, in a controlled way;
• keeping the images within our own infrastructure;
• integrating with the existing backup and replica system.

This part would be a natural evolution of the project: moving from "I have the files stored" to "I also have personal services on top of my files".

16. Hardware used

Each installation consists roughly of:

• Raspberry Pi;
• 16 TB SATA hard drive;
• USB-SATA adapter compatible with large drives;
• power supply suitable for the drive;
• case, rack or physical mount;
• additional ventilation;
• home network connection with fiber.

An important detail is that not all USB-SATA adapters work correctly with high-capacity drives. In some cases there can be limitations of the chipset, the firmware, the type of USB-SATA bridge, UASP support, the handling of large sectors or simply compatibility problems with modern multi-terabyte drives.

For this reason it was necessary to choose a more reliable adapter, even if it was more expensive.

17. Cooling, noise and physical stability

The drive temperature is an important factor for the longevity and stability of the system.

In my case, the drive is mounted inside a metal structure designed for several drives, although I currently use only one. This provides more metal mass and therefore more dissipation capacity.

In addition, the rack has a fan controlled by PWM from the Raspberry Pi. This allows adjusting the fan speed, reducing noise and keeping the drive at a reasonable temperature.

Figura 7

The goal is not to cool aggressively, but to prevent the drive from running hot for many hours. A drive that stays warm and stable is preferable to a drive subjected to thermal peaks or poor ventilation.

18. The fan case: when plug and play isn't

Another lesson from the project is that home hardware is rarely as plug and play as it promises.

In my case, I bought a case or rack that theoretically came ready, with a fan included. The idea was simple: mount the drive, connect everything and let the system run.

But the fan that came as standard had a clearly defective behavior: what heated up was the fan itself, not the drive it was supposed to cool. At idle, with no real load to justify it, the fan reached about 70 °C in a few seconds. In other words, it was not the drive that was at 70 °C, but the fan itself, which was neither acceptable nor safe.

Since it had to be replaced anyway, I changed the original fan, about one centimeter thick, for another two centimeters thick. Thicker fans can move air with less effort and, in general, can be quieter for the same airflow. This was important because the server is installed in the living room, where noise is a real factor.

The change was not immediate either. I had to use the 3D printer to make cylinders or adapter spacers that allowed the new fan to be mounted correctly in the existing case.

This episode sums up the character of the project very well: on paper, it seems to be just "a Raspberry Pi with a drive". In practice, many small but important details appear:

• USB-SATA adapter compatibility;
• drive power;
• temperature;
• noise;
• vibrations;
• physical mounting;
• airflow;
• adapted parts;
• PWM control;
• placement within the house.

Each detail may seem minor, but all together they separate an improvised setup from a reasonably reliable system.

19. Monitoring and checks

The system incorporates several periodic checks.

Before starting an important copy, the drive's health is queried with smartctl. If the drive reports a problematic or pre-failure state, the copy can be skipped to avoid writing to a potentially defective medium or aggravating a delicate situation.

In addition, there is an hourly check that verifies the machine is reachable and that the drive remains mounted or available. This check also queries the free space using df.

Once a day, around 7 in the morning, a message is sent via Telegram with the general status. This way, important problems do not stay silent for weeks.

So far, Telegram has never failed us. Besides, this daily message works as a kind of dead man's switch: we check it every morning at 7, so if one day it didn't arrive, the very absence would be the alarm and we would worry immediately.

Figura 8

One point that needs strengthening is the regular review of the backup status. It is not enough to generate logs: you need to make the final status visible.

A clear improvement would be to incorporate into the daily Telegram message information such as:

• last successful copy of each machine;
• duration of each copy;
• amount of data added;
• number of files processed;
• status of the Borg repository;
• result of the last borg check, if it is run periodically;
• remaining free space;
• SMART status and drive temperature;
• the time offset between the nodes (they all set their clock via NTP, but checking it periodically helps detect clock problems);
• an explicit warning if a copy has gone more than X days without completing.

This would turn monitoring into a tool of real trust, not just a superficial availability check.

20. Drive sleep management

Hard drives can be put to sleep after a short period of inactivity. This reduces power consumption, noise and mechanical wear, but it also introduces a tension between two goals:

• not waking the drive unnecessarily;
• detecting problems quickly enough.

For this reason, it is advisable to group heavy operations into specific time slots, especially the nightly copies. You also have to avoid checks that are too intrusive every hour if that forces the drive to spin constantly.

The practical rule is that frequent checks should be lightweight, and operations that clearly wake the drive should be justified.

21. Git repositories encrypted with git-crypt

In Ismael's case, another interesting line has been the use of Git repositories with content encrypted using git-crypt.

git-crypt is a tool that allows transparently encrypting certain files within a Git repository. The files configured as sensitive are stored encrypted in the repository, but authorized users see them decrypted in their working tree. The project's official description is precisely "transparent file encryption in git".

This is useful when you want to keep a normal Git repository, but without exposing secrets, private configurations, keys, personal data or files that should not be in plaintext.

Figura 9

This fits well with Tocho's general philosophy: not relying solely on the system perimeter, but also encrypting the data according to its specific use.

In other words, there are several layers of protection:

• GoCryptFS for encrypted file trees;
• Borg for versioned, deduplicated and encrypted backups;
• git-crypt for secrets or sensitive files within Git repositories;
• SSH with restricted keys to limit what each machine can do;
• separation between live data and historical copies.

The common pattern is clear: each tool protects a different part of the problem.

22. Risks covered

Tocho covers several risk scenarios fairly well.

Drive failure

If a drive fails, there is still a replica in the other location. In that case, you have to buy a new drive and rebuild the copy.

Theft

If one of the machines is stolen, the other person's data is still in another house. In addition, the data hosted on the stolen drive is encrypted.

Fire or local physical damage

A catastrophe affecting a single location should not destroy all copies.

Partial human error

If something is accidentally deleted and the copy has not yet been synchronized, it may be possible to recover it from the previous replica. That said, this protection is limited if the deletion or corruption has already propagated with rsync.

Compromise of a client machine

With Borg append-only and restricted SSH keys, a compromised client machine should not be able to permanently delete all historical copies.

23. Risks not fully resolved

The current system still has significant weak points.

Silent corruption

If a file becomes corrupted and is then replicated, the remote copy may also end up containing the corrupted version. rsync is not, on its own, a system for historical integrity verification.

Ransomware on live data

If a client machine massively encrypts or modifies the visible files, and a synchronization is then run, the damage can propagate to the replica.

Partial absence of history

A simple replica protects against the loss of a drive, but not always against logical errors. For that you need snapshots, old versions or immutable copies for a period.

Vulnerability window

Between a local modification and the remote copy there is a time window in which the new data still exists in only one place.

Slow rebuild

In the event of losing a complete drive, rebuilding 16 TB can be slow. At a sustained 100 MB/s, copying 16 TB takes approximately 44 hours. In practice, it can be more, because the real performance depends on the drive, the network, the encryption, the protocol and the number of files.

For this reason, in a full rebuild it may be more reasonable to physically take the drive to the other house and make the first copy locally or over a fast local network.

24. Disaster recovery

In the event of a complete drive failure, the general procedure would be:

1. Detect the failure via SMART, I/O errors or absence of the drive.
2. Mark the affected node as unreliable.
3. Stop automatic synchronizations to that drive.
4. Buy or install a new drive.
5. Initialize the file system.
6. Restore the copy from the other server.
7. Verify the integrity and mounting of the encrypted system.
8. Reactivate the nightly copies.

During the rebuild, the system is in a more delicate moment, because temporarily there may be a single complete copy. For this reason you have to minimize the rebuild time and avoid risky operations until redundancy is restored.

25. Possible improvements

The project is already useful in its current form, but there are several possible improvements.

Persistent "suspect drive" state

If smartctl detects a pre-failure situation, it is not enough to skip one particular copy. It would be advisable to leave the drive in a persistent state of "blocked", "suspect" or "requires manual intervention".

This would prevent a later run from automatically trying to copy again until someone reviews the problem.

Periodic active SMART tests

Currently only the SMART attributes are read before each copy, but no active tests are run. It would be a good idea to schedule a long test (smartctl -t long) once a month: it scans the entire surface of the drive and can detect defective sectors before they cause problems. Since it is a slow operation that keeps the drive awake, it is best to run it in a nighttime slot and record the result in the daily alert.

Snapshots or versions

To better protect against ransomware, accidental deletions or logical corruption, it would be interesting to add some versioning mechanism.

Some options would be:

• snapshots with Btrfs or ZFS;
• copies with rsnapshot;
• BorgBackup or Restic repositories;
• hard links with strategies like rsync --link-dest;
• retention of daily, weekly and monthly versions.

Integrity verification

It would also be useful to have a catalog of hashes or a periodic verification system that allows detecting silent corruption.

The challenge is to do it without continuously waking the drive or turning verification into an overly costly task.

Detecting suspicious changes

Another interesting idea would be a system that automatically detects suspicious changes in files before propagating them to the replica. For example, if a file changes type —as the file tool would identify it—, it could be a sign of corruption or of ransomware encryption: a document that suddenly becomes an opaque binary, or a bunch of files that change type all at once, is an anomalous pattern. Detecting it would allow pausing the synchronization and raising an alert before the damage reaches the remote copy.

Restore tests

A backup that has never been restored is just a hypothesis. For this reason it would be healthy to do periodic restore tests, even if they are partial.

For example:

• restoring a random directory;
• verifying that GoCryptFS can be mounted from another machine;
• verifying that Borg can restore old files;
• documenting the recovery steps;
• confirming that the necessary keys are available.

26. Lessons learned

One of the most important lessons of the project is that setting up your own alternative to cloud services is not free, even if you don't pay a monthly fee.

The cost is not just the drive. You also have to take into account:

• the price of large drives;
• compatible and reliable USB-SATA adapters;
• power supplies;
• cases, racks or physical mounts;
• cooling;
• noise;
• electricity consumption;
• administration time;
• monitoring;
• restore tests;
• key management;
• documentation;
• incident response.

For this reason, being against paying for a cloud service just because "I can do it myself for free" is a dangerous oversimplification. The reality is that doing it well requires money, time and knowledge.

The conclusion is not that the cloud is always better. The conclusion is more nuanced: the commercial cloud can seem expensive until you add up everything that operating a reliable infrastructure yourself entails.

In our case, Tocho makes sense because we learn, we control the data, we have technical ability and we are interested in the process. But it is not a magic or free solution. It is real infrastructure, even if it is homemade.

27. Future direction of the project

The natural direction of Tocho is to evolve from a replicated NAS toward a hybrid system:

• NAS for large files and convenient access;
• Borg for versioned backups;
• SSH keys restricted per machine;
• append-only to reduce the risk of remote destruction;
• controlled pruning from the server;
• daily monitoring that is genuinely actionable;
• separation between live data and historical copies;
• personal services on top of the files, such as a future in-house photo management.

This evolution makes the system more resilient not only against physical failures, but also against human errors, faulty scripts and ransomware attacks.

28. Summary: steps to build your own Tocho

If someone wants to replicate a similar setup, these are the basic steps, in roughly this order:

29. Final visual summary

Figura 10

30. Conclusion

Tocho is a home system for distributed storage and backup that combines NAS, remote replica, encryption and versioned copies.

Its value does not lie only in the available terabytes. It lies in control: control over where the data is, who can read it, how it is mounted, how it is copied, how it is monitored and how it is restored.

Its natural evolution is to reduce direct access to critical files and increase the weight of append-only repositories, which are more resistant to human errors and ransomware.

In short, Tocho is a personal infrastructure of technical sovereignty: not perfect, not free and not trivial, but understandable, repairable and adapted to our real way of working.