A simple strategy to avoid losing your work environment
One of the most common mistakes in computing is remembering backups only when it is already too late.
When the disk fails.
When an update breaks something.
When we accidentally delete a folder.
When a laptop stops booting.
When that “temporary” file turns out to be important.
In the world of development and system administration, we usually spend a lot of time fine-tuning our environment: configurations, scripts, keys, projects, documents, dotfiles, profiles, tools, notes, and small adjustments that make a machine truly ours.
The problem is that, many times, all of that lives in only one place.
And if that place fails, we lose much more than files: we lose time.
Backup as a habit, not as an event
A backup should not be a heroic task we perform once every six months. It should be something simple, repeatable, and easy to run.
That is where rclone becomes a very interesting tool.
rclone allows you to synchronize files between a local machine and multiple remote services: Google Drive, OneDrive, S3, Dropbox, SFTP servers, WebDAV, and many more. Its great advantage is that it works from the terminal, can be automated, and allows you to define precisely what to copy and what to ignore.
A concrete example:
rclone sync "/home/carlos/" "midrive:Backup_${NOTEBOOK}" \
--exclude ".cache/**" \
--exclude "Downloads/**" \
--drive-chunk-size 64M \
--progress
This command looks simple, but it contains a fairly solid strategy.
What this command does
The main instruction is:
rclone sync "/home/carlos/" "midrive:Backup_${NOTEBOOK}"
This synchronizes the contents of /home/carlos/ to a remote destination called midrive, inside a folder whose name depends on the ${NOTEBOOK} variable.
In other words, if the NOTEBOOK variable is set to thinkpad, the destination could look like this:
midrive:Backup_thinkpad
This makes it possible to keep separate backups for each machine. That is very useful if we work with more than one laptop, a desktop PC, or different environments.
Backing up a personal machine is not the same as backing up a work machine. Separating backups by device name avoids overwriting information and keeps remote storage more organized.
Synchronizing is not the same as copying
The key word in the command is sync.
And this is important.
rclone sync does not simply copy new files. What it does is try to make the destination match the source.
That means that if a file exists in the remote backup but no longer exists in /home/carlos/, rclone sync may delete it from the destination.
This has advantages and risks.
The advantage is that the backup stays clean, up to date, and does not accumulate old junk indefinitely.
The risk is that if we accidentally delete something on the local machine and then run the sync, that deletion may also be replicated in the backup.
That is why, for certain critical cases, it may be a good idea to complement this strategy with versioning, snapshots, or historical backups. But for maintaining a mirror copy of the work environment, sync is a very powerful option.
What is excluded and why
The command excludes two paths:
--exclude ".cache/**"
--exclude "Downloads/**"
The first exclusion avoids copying the .cache folder.
This makes a lot of sense. Cache usually contains temporary files generated by applications, browsers, package managers, graphical environments, and development tools. It can take up many gigabytes and, in most cases, is not worth backing up.
Copying cache to the cloud means wasting bandwidth, storage space, and time.
The second exclusion avoids copying Downloads.
This is also reasonable. The downloads folder is often full of installers, temporary files, duplicated PDFs, loose images, and things that are not necessarily part of the important environment.
In other words: the backup should not become a remote trash bin.
It should store what really matters.
The Google Drive detail
The option:
--drive-chunk-size 64M
is related to the Google Drive backend.
When rclone uploads large files to Drive, it can split the transfer into chunks. Adjusting the chunk size can improve upload performance, especially on stable connections and with large files.
A 64M chunk is a reasonable choice: it is not too small, which could generate too many operations, and not absurdly large, which could consume more memory than necessary.
It is not a perfect universal configuration, but it is a good practical starting point for a personal or work environment.
Seeing progress matters
The option:
--progress
allows you to see the progress of the synchronization.
It may seem like a minor detail, but it is not. When a backup takes several minutes, we do not want to stare at a silent terminal without knowing whether something is working, frozen, or transferring a huge file.
Seeing progress helps us trust the process.
And when we trust the process, we are more likely to repeat it.
A minimal but effective strategy
What is interesting about this command is that it does not try to solve every possible problem in the world of backups.
It does not implement advanced deduplication.
It does not create historical snapshots.
It does not automatically encrypt every file.
It does not build an enterprise architecture.
It does not depend on a heavy graphical interface.
It does something simpler: it synchronizes the user’s home directory to a remote destination, avoiding unnecessary folders.
And that, for many cases, is already a huge improvement over having nothing.
Because the best backup is not the most sophisticated one.
It is the one that actually runs.
Automating it
Once tested manually, this type of command can become a script:
#!/bin/bash
NOTEBOOK=$(hostname)
rclone sync "/home/carlos/" "midrive:Backup_${NOTEBOOK}" \
--exclude ".cache/**" \
--exclude "Downloads/**" \
--drive-chunk-size 64M \
--progress
With that, the machine name is automatically taken using hostname.
After that, it can be run manually, added to cron, integrated with systemd timers, or launched when shutting down the machine.
The key is for the process to be simple enough that we do not abandon it.
Backup is not paranoia
Sometimes backups are discussed as if they were an obsession of system administrators. But in reality, they are a basic form of respect for our own time.
Losing files hurts.
But losing configurations, environments, and years of small adjustments hurts even more.
A well-designed backup does not only protect documents. It protects continuity.
It allows you to switch machines faster.
It allows you to recover from mistakes.
It allows you to reinstall without starting from scratch.
It allows you to work with less fear.
Conclusion
This rclone command summarizes a very practical philosophy:
Back up what matters.
Exclude what is disposable.
Separate backups by machine.
Use the cloud as a remote destination.
Keep the process simple and repeatable.
There is no need to wait until we have a perfect infrastructure to start protecting our environment.
Sometimes, a single well-thought-out line is worth more than a complex strategy that never gets executed.
Because in computing there are two types of people:
those who make backups, and those who have not lost anything important yet.
rclone allows you to be in the first group without making life complicated.
Comments
Post a Comment