Hi guys !
My problem seems to be quite basic but I can’t find any solution in the forum. Hope i haven’t missed something obvious.
- have dietpi 6.33.3 installed on a rapsberry
- moved dietpi_userdata to external SSD drive for space, efficiency, consumption and noise purpose. I used the option in the drive manager to do that.
Everything seems to work fine… except using dietpi-backup does not backup my dietpi_userdata folder… Among other things I have a Nextcloud app installed with data located in that userdata folder. I Would like it to be saved with dietpi-backup.
The backup process seems to go all the way correctly, backing up to a second external drive.
In dietpi-backup custom filter option, it is said that dietpi_userdata is still included even if moved to a custom location.
Since it was not backed up, I used custom filters and tried to add a custom directory on the external drive “/mnt/dietpi_userdata/nextcloud_data/”.
didn’t work.
And by the way, I also couldn’t find a direct way to schedule backups using this dietpi backup software.
Thanks for the help and big thanks for the Dietpi team for all the work done.
Sofiann.
Hi,
many thanks for your message. If I’m not mistaken /mnt/* is excluded by dietpi-backup. Except /mnt/dietpi_userdata/ nothing should be saved on /mnt/*. Something MichaIng would need to confirm.
Probably you would need to create your own rsync script to backup your external disk
/mnt/dietpi_userdata is currently only included into the backup if it is located on the same drive. If it has been moved to an external drive, it is skipped like all other /mnt/* content.
I’m not happy with this, since it is inconsistent and not documented at all, however I’m not sure how to handle best, especially when again restoring data. If personal downloads, media, software-specific databases and such are located on /mnt/dietpi_userdata, then restoring it would mean to overwrite/remove current data. More difficult when during backup and restoring, dietpi_userdata have been moved to an external drive or back to rootfs. Then the /mnt/dietpi_userdata directory could be completely removed and replaced by an obsolete symlink or a symlink pointing to the actual external drive replaced with an obsolete directory. The way the script currently does it, at least prevents any accidental data removals, which is why I wasn’t brave enough to change something yet, without investing some brain time into a robust concept.
Best would be probably to by default include everything (all /mnt content, only excluding known temporary/device/kernel meta file locations) content into the backup but exclude all /mnt restoring. Then a list in the GUI should show all exclusions (separately for backup and restore) and below each the related inclusions, in case, and allow GUI-based adding/removal of exclusions and inclusions. A reason for a GUI is that when exclusions/inclusions are added in wrong order, they do not work, as rsync applies the first match from the list, even if a more specific one is present below. So based on a tree structure we can apply exclusions+inclusions in the correct functional order, error out on ineffective/conflicting rules etc.
Hi everyone and happy new year to you all !
Thanks a lot for your answers Michalng and Joulinar. This helps a lot.
Moving user_data to another drive seems to be troublesome so I may move it back to SD card and set softwares (like Nexcloud) to locate their folder on external drive. Then use rsync script to automate backup.
Keeping dietpi_userdata on external drive and creating an rsync script to backup, compared to moving it back to SD card + moving Nextcloud data to external drive + creating an rsync script to backup Nextcloud data, efforts should be the same? 
However, shouldn’t play a role when Nextcloud is the main role of your DietPi anyway.