@jdaviescoates The first one is from redis, it can be ignored. The second is the healtheck bot. It appears when the app is not up yet. That can be ignored as well. The final one is because the apache config has ServerName unset. Which app is this? Setting the ServerName to some dummy name makes it go away.
@scooke I went to each individual app and pointed to the fileshare with the full path "/media/fileshare/2020-07-01-0500/app_backup.tar.gz.enc" and restored those backups.
As for the second part, Azure adds the following "actimeo=30" switch to the cifs share that goes in your /etc/fstab file that causes the connection to time out if the backup takes too long. Once that is removed, reboot the server and the new backups will complete without issues.
Just to let anyone else know, I ran into the same issue with 7.2.0 when migrating servers and made the change that @girish mentioned and it still didn't work until I restarted docker (systemctl restart docker) and then it worked!
@MOrochena Ah yes, restores across different versions is not supported. Ideally, the error message could have been better though, I will fix that (i.e it should have said the version does not match instead of saying 'remotePath' must be a string!
Note to self: Use an external drive that has twice the disk space needed by the apps as a temporary mount point to restore to! Because it will need to download a copy of the whole backup, then unpack and finally bin the download. D'oh!
Step 1: Find a disk with sufficient space to restore to (apps space x 2)
Step 2: Mount the disk and symlink to the original location in the backup file
Step 3: Restore and then reset the storage location (or point it to where ever your new mount point is).
Got it all working now. Perhaps it's time to invest in a bigger SSD for my home server 🙂
I have the .zip file. Cannot figure out why I keep getting "backupFolder path is protected"
You can only create backups to specific paths on the server. Many of the paths are "protected" to make sure that the folders won't get overwritten by updates or are used by the system. This is just a hardcoded list of paths:
(the baseDir above is /home/yellowtent/). You cannot create backups in subdirectories of the above paths.
I understand you are using restore here though and not backup 🙂 The restore logic uses the same validation logic for paths and you have copied the backup to under /home/yellowtent/. Instead, copy the backup in some path like /mnt/backups/ or /srv/backups/ and try to restore, that should work.
@girish Well, it was incredibly satisfying to see these important apps, which I use the most, get restored first. Would it be difficult to "rank" apps by usage, which could then be used for Install by Restores, or Migrations?
Anyway, it worked out super well for me. Thank you!