[Xiaomi Mi A2 Lite Guides, News, & Discussion] a1291762:
In case this guide failed to give it away, I'm very familiar with low-level Linux things. The way I do backups reflects this. I'm not sure that the way I do backups is useful for the average person, but if you're into doing things the hard way, you might like it.

I don't do cloud backups. I don't trust them. I have only recently had enough bandwidth to even consider it. I know that the Android cloud backups often miss things too (apps have to opt-in rather than opting out). Back when I started on Android, cloud backups weren't even a thing.

I backup apps with Titanium Backup. I've used it across half a dozen devices and as many Android versions. I have sometimes thought about trying other backup tools but I'm familiar with this one. I backup to a local folder on the phone (sometimes on an external SD card, currently just on the internal storage). I don't backup system data anymore, just call history and SMS messages as XML (restoring system data with Titanium stopped working well some time ago). I have some schedules set up. New apps and upgrades are backed up daily but changed data is only backed up once a week. In theory (and multiple times in practice) I can take this backup and restore it to a new phone.

What Titanium doesn't do is to backup the /sdcard directory. Several phones ago, I came up with a combination of ssh and rsync binaries. I have had to update these binaries a few times as the old ones stopped working. I'm not entirely sure where the current binaries I use came from! The ssh can get to my local (Ubuntu) server without a password and rsync lets me update the copy of files on the server with what's on my phone. I had to create a key pair... The ssh binary is dropbear, so you'll need a dropbear-format private key (use dropbearkey instead of ssh-keygen). https://yasmar.net/files/rsync.tgz

I use cron to run a script every night. I currently use an app called crond (https://f-droid.org/en/packages/it.faerb.crond/) that requires manually creating /data/crontab:

0 3 * * * cd /sdcard/work && sh ./backup.sh > backup.txt 2>&1

My backup script copies Titanium and /sdcard separately, even though Titanium is under /sdcard. A previous phone had Titanium on an external SD card so the dual-backup was important. Also, I backup the Titanium folder differently.

#!/bin/sh
woody=10.1.1.12
tmp=/data/local/tmp
set -x
date
cd /sdcard/work
cp rsync ssh id $tmp
chmod 755 $tmp/rsync $tmp/ssh
chmod 600 $tmp/id
ssh="$tmp/ssh -y -i $tmp/id"
$tmp/rsync -e "$ssh" \
-rltv \
-p --chmod=u=rwX,go=rX \
/sdcard/TitaniumBackup/ \
link@$woody:~/Files/MIA/TitaniumBackup/
$tmp/rsync -e "$ssh" \
--exclude=com.google.android.videos \
--exclude=.hermit \
--exclude=.fileVault.0 \
--exclude=RIL_offline \
--exclude=cache \
--exclude=.git \
--exclude=TitaniumBackup \
-rltv --delete \
/storage/emulated/0/ \
link@$woody:~/Files/MIA/sdcard/

To explain that a bit...

The binaries and identity file are copied to /data/local/tmp so they can be made executable and run.

I rsync TitaniumBackup to my server without deleting old files (my server has a year's worth of backups, while my phone only keeps a few backups, I think the limit I set is 5).

Then I rsync /sdcard to my server, ignoring some directories that I've observed being large (or useless). Probably some of those folders aren't even necessary anymore. Unlike the TitaniumBackup folder, the server is kept in sync (no history, just a duplicate of /sdcard).

This backup uses local IPs, so this only works if I'm at home and connected to wifi.

In theory, to restore on a new phone or if I've done a factory reset, I just need to copy the /sdcard files and the TitanumBackup folder, install Titanium and restore the apps. I had a couple of factory resets on my A2 Lite when I got it (because I kept breaking things) and I could get it up and going again in about 2 hours. A lot of that time is re-doing system settings.

In my case, because my server keeps so many backups, I have to use a script that grabs the most recent of each app only. I could share my scripts if you really want, but they're kind of hacked together, written in perl and probably have very rough edges. One of the things they do is to remove old backups, so there's clearly potential for trouble (removing more than you'd hoped for).

I can look at the backup.txt to make sure things are working. I have a cron job on my server to make sure that the phone has backed up (emails me if it failed). Mostly that results in me getting emails when I'm not at home overnight, but sometimes something on the phone will go wrong and the rsync to the server will fail.