This has saved my life a few times but a couple of observations when restoring from newly flashed SD card on XU4:
If you have moved your default user data elsewhere you need to move it back or else some services won’t start.
It hasn’t restored /var/www fully and I have noticed this a few times on different versions of dietpi. Easy to fix manually but I wonder what the reason is? I reported this in the forum a while back but Fourdee couldn’t reproduce.
John
johnvick
Many thanks for your report.
Hmm strange about the userdata, I was thinking it just restores from the backup into the /mnt/dietpi_userdata symlink target, regardless where this is pointing to. Does it always create a dir in rootFS?
As well strange about /var/www. Could you find some hint in the log of dietpi-backup after restoring? Any symlinks placed inside that point to another drive? Since fstab is restored as well, perhaps some old mount point does not exist anymore leading to wrong symlink targets or such.
I’d have to restore another backup to check this out - I hope the oppurtunity doesn’t happen 
All I can remember is if you start with a newly flashed SD, move the userdata folder and then restore from backup all goes well.
If you restore and then move the userdata folder it all works but before you move the userdata you get some services not working.
As the the /var/www problem - I have only one link in there, phpmyadmin. I’ll see if I can find some logs.
John
Edit - unfortunately restore log was overwritten.
I just made some test:
But if userdata is already on an external drive, e.g. /mnt/sdb/dietpi_userdata, it is actually not backed up 
. The way we add includes/excludes does not include any sub dir of /mnt/ (besides /mnt/dietpi_userdata) and does not follow (or even include) the /mnt/dietpi_userdata symlink into the backup.
Usually this is okay if stuff is on an external drive anyway, but actually the idea that time was to include dietpi_userdata into the backup in every case. There is an inclusion rule for this, but it has no effect since the related subdir (e.g. /mnt/sdb/) is not even entered.
And since the old fstab is recovered, the userdata mount can be missing after reboot, at least if one does not open drive manager before reboot to auto-readd the active mount.
That is actually an issue in case of some programs which have files in userdata and if the current installed version/files in RootFS do not match and are not compatible with the ones in userdata (e.g. MariaDB version and database files in /mnt/dietpi_userdata/mysql). So it would make sense to change the include/exclude rules so that external userdata + symlink is backed up as well.
But then another issue can occur:
If you backup with external userdata and before restoring, move the userdata back to RootFS, then the symlink overrides the current userdata. And since the previous userdata dir is not inside the include list (only the current one), it is not restored.
Can be as well solved by adding the old userdata dir to the include list before restoring. This will be in RootFS then in case the mount does not exist anymore, so e.g. /mnt/sdb/dietpi_userdata but not as a mount. It can be moved again to an external drive from there, but if userdata were very large (much media, downloads and such), the RootFS (SDcard) can easily not have enough free space for restoring.
And generally when recovering userdata:
Actually content in userdata/Music|Video|Pictures|downloads should not be restored, at least not the way that files that are not present in the backup, are removed. In case of some strange/broken system, you want to recover system and programs, which must include removing newly created files, but newly created media files and downloads should be preserved. This makes the include/exclude rules even more complicated when resolving the above issues with changed userdata.
Puuuuh complicated thing…
Actually I believe the best is to compare userdata location from backup with the current one and abort restoring the backup if it does not match. So first user must in case restore the old mount + move userdata back. And then on restore we can ask user if Musik/Video/Pictures/downloads should be restored as well or not. When restoring onto a fresh SDcard, you usually want it, when restoring to repair a broken system, e.g. failed update, bad software install or such, you usually want to keep media as is. The question can be skipped for empty media dir of course.
Additionally we should prompt a hint when moving userdata, that an existing backup should be updated afterwards to have correct userdata location and related fstab entry there as well.
Okay larger topic. At least the current behaviour does never destroy something. Have to sleep about it to hopefully find a more elegant solution, e.g. automatically recovering old userdata (skipping media/downloads) to the new userdata location and preserving/re-adding the related fstab entry…would be nice…