Traversing Unix File System as Source

1

I’m using a Raspberry Pi with RaspberryPi OS, essentially Debian 64bit.
The files I want to back up are in the users own workspace which has the absolute path:
/home/<user_name>/<subdirs>

The directories I want to back up are within a docker folder and can ordinarily be accessed as ~/docker/<subdirs>, but as, duplicati requires absolute paths beginning with “/”, this translates to:
/home/<username>/docker/<subdirs>
The source filesystem tree (step 2) shows “home” (see attached) but nothing below this. It cannot be expanded and, when backed up, contains little more than the .profile file.

The other source location, “My Documents” seems to be MS Windows filesystem…

If I try adding the path manually, Duplicati reports the path doesn’t exist.

So, I’m confused as to how/where to specify the user home directory. Thoughts?
Thanks,
Ric

Screenshot 2024-10-09 204104

Nagging thought: the docker compose file has:
image: duplicati/duplicati
It’s not the wrong image for ARM64 architecture???

2

After a bit more digging around…, the user folders are found in:
/source/home/<username>/<subdirs>/

3

I think docker-compose will use the OS arch as the default, so you should get the correct version.

4

think docker-compose will use the OS arch as the default, so you should get the correct version.
Yes it does.
Since the initial hiccup duplicati has been working consistently well, both on backups and restores.

I try to hack things a bit to see what happes when things go wrong, so I deleted a set of the backup files. Duplicati detected this but was unable to resolve the missing files (either by restoring them or by removing references to them) using the “Repair” option. I fact the only way I could remove the warning was to remove the docker volume and start over - which is fine for experienting with, but not good if the remote files go awry.
Regards,
Ric

5

The way to handle this is manual fix as below, assuming it was the big dblock files lost.

Recovering by purging files

If the small dindex and dlist files disappear and database is intact, Repair will reupload.

6

I deleted all three files simulating a catastrophic failure of the backup medium.

This seemed to me to be the best test.

My solution is to have two backup tasks; the first to backup in “nn” hours to my local Synology NAS, the second to OneDrive or some other remote server using the Smart Backup option. If the former fails, the latter is always available.

Ric

7

If everything on the Destination disappears, the backup is lost, but plan for a spare should help. Destination somehow reappearing empty-but-working just needs database delete to fresh start.

8

Hello, and many thanks for your reply.

I am extremely pleased with Duplicati. I have tried others that offer a GUI but have had huge problems with them. Duplicati just seems to work, pretty much “out of the box”.

I have been able to create regular, short-term backups to my Synology NAS via WebDAV and a longer-term schedule to OneDrive using the Smart Schedule. I am hugely confident, given my attempts to break the system, that Duplicati has sufficient resilience to just keep going.

I keep (and maintain) a backup image that I can reinstate to any Raspberry Pi so that Duplicati is ready to restore a backup. Further, data follows a chain so that all collected data converges to an InfluxDB instance that acquires data from a number of sources and that too will be backed up independently before being presented to Grafana.

Maybe beyond that lies paranoia, but for now I can sleep at night knowing really useful - but not life determining - data is preserved.

Kind regards,
Ric

1 Like