Restoring from backup has no effect

[DmitriyYukhanov]

Hey,

Thanks for making this great tool, it was relatively easy to get it up and running on my rPi, but now I'm stuck with restoring data from the backup.

What I did:

• install using docker standalone

• configure, play around a bit

• save backup using Backup button

• kill running instance, remove container and image

• install using docker-compose from downloaded release

• attempt to restore from backup using steps from the wiki

  output

  ```
  pi@raspberrypi:~ $ export BACKUP_PATH=/home/pi/changedetection-backup-1636402504.zip
  pi@raspberrypi:~ $ docker run -v datastore-volume:/datastore -v $BACKUP_PATH:/backup.zip python:3.8-slim bash -c "apt-get update && apt-get install unzip -y; unzip -o /backup.zip -d /datastore"
  Get:1 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
  Get:2 http://deb.debian.org/debian bullseye InRelease [116 kB]
  Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
  Get:4 http://security.debian.org/debian-security bullseye-security/main armhf Packages [83.3 kB]
  Get:5 http://deb.debian.org/debian bullseye/main armhf Packages [7942 kB]
  Get:6 http://deb.debian.org/debian bullseye-updates/main armhf Packages [2600 B]
  Fetched 8227 kB in 4s (1958 kB/s)
  Reading package lists...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Suggested packages:
    zip
  The following NEW packages will be installed:
    unzip
  0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
  Need to get 157 kB of archives.
  After this operation, 305 kB of additional disk space will be used.
  Get:1 http://deb.debian.org/debian bullseye/main armhf unzip armhf 6.0-26 [157 kB]
  debconf: delaying package configuration, since apt-utils is not installed
  Fetched 157 kB in 0s (892 kB/s)
  Selecting previously unselected package unzip.
  (Reading database ... 7016 files and directories currently installed.)
  Preparing to unpack .../unzip_6.0-26_armhf.deb ...
  Unpacking unzip (6.0-26) ...
  Setting up unzip (6.0-26) ...
  Archive:  /backup.zip
  inflating: /datastore/url-watches.json
  inflating: /datastore/secret.txt
  inflating: /datastore/4edc5a65-ce60-4055-a854-6f6e54058d09/8666d3f1-9714-41d1-8e91-eb71417b5b93.stripped.txt
  inflating: /datastore/url-list.txt
  pi@raspberrypi:~ $ docker restart changedetection.io
  changedetection.io
  pi@raspberrypi:~ $   
  ```
  

• after running these commands, I still see backup not applied as current instance has old settings and url list

I've checked out logs from docker logs changedetection.io &> logs.txt and didn't find anything abnormal or related to the backup restore procedure.

It's not that hard to redo all the configuration, but it would be nice to get it working for the future cases where config might be much more complex and harder to recreate from the ground up.

I'm new to the Docker and mostly Win user, so I just easily could do something wrong =(

[kristjanvariksoo]

I had this same issue. Seems like the instructions dont actually work. Solved it by manually doing it as follows:

• Killed docker container
• docker ps -a to find name/id of container
• docker inspect -f '{{ .Mounts }}' changedetection with changedetection as name of container to find the location of the volume on the host machine
• Copied zip file to that host filesystem folder and unzipped it
• Restarted docker container

[Aducarab]

I can confirm this is still an issue with version v0.45.3 on a Raspberry Pi OS / Bullseye with Docker Compose

@dgtlmoon I have the exact same behavior as described by DmitriyYukhanov --> the restore is just not working.

The approach described above by kristjanvariksoo works for me and I was able to successfully restore a quiet large and complex config.
Note I use at the end the following restart comand: sudo docker-compose up -d

[makanimike]

I too have the problem. If I follow the official instructions, everything (appears to have) executed correctly. But nothing actually changes in the app.

Unfortunately, I am not able to use kristjanvariksoo's work-around. I am not allowed to access the location of the volume. I sudo'd in all ways I know of, but I cannot get in.

[shaunkoh]

Just +1 this problem and solution. The last hour was terrifying after the wiki instructions didn’t work for me. Here’s the full set of steps I took that worked for me.

1. Stop the current container (sudo docker kill changedetection_changedetection.io_1)
2. Cd to docker datastore file directory location (mine was cd /volume1/docker/changedetection)
3. Place the backup zip file there.
4. Unzip in place (For synology, 7z x changedetection-backup-XXXXX.zip)
5. sudo docker-compose up -d

Worked for me on v0.45.8.1, coming from V0.39.

I have no idea why the wiki’s one line unzip command doesn’t work.

[edoardottt]

@kristjanvariksoo or someone else has a oneliner to share?

[matheusfaustino]

I know it is old, but just give my two cents: the problem with the command from the wiki is the column name, I changed it, and it worked without issue, even without the chmod.

If you have access to docker desktop, you can go to the container page and see the name of the volume there. Substitute it in the script and one, if it works, you will see all your files in the tab files and can double-check its content. Mine ischangedetection_changedetection-data. I am using docker-compose file to run.

[morenone]

I tried all the above steps to no avail. Then I changed the permissions inside the datastore folder to 777 and everything worked.

[logkirk]

I could not get above steps to work, including the chmod 777 suggestion. I'm not sure why this was migrated to discussions, but I think this should be re-opened as an issue.

[giuliovrz]

I tried all the steps above and none worked, then I tried leaving the original "secret.txt" file in the /datastore folder of the container and copying all the other folders and file from the backup zip and that worked.