Restoring backup from another server does not work using restore script

[ericxw]

Describe the bug

Upon restoring a backup file from another server using docker exec -it palworld-server restore, the hash in /palworld/Pal/Saved/Config/LinuxServer/GameUserSettings.ini remains unchanged. Thus game loads with incorrect save state.

I presume that backup and restore works for backups made on the same server since the hash would remain the same.

To Reproduce

Steps to reproduce the behavior:

1. Create new server through Docker
2. Copy backup file from another server into backup folder of restore server
3. Run docker exec -it palworld-server restore and select correct backup file, answer 'y'
4. view GameUserSettings.ini file to see that hash has not changed and is different from the config file from the backup file when manually extracted.
5. Connect to game from Palworld game, the game prompts to setup game character. (note that while the restore script instructions says to restart server manually, the server has been restarted already.
6. If I shutdown the container and manually modify the config file, then start the server now, the expected save state is loaded.

Expected behavior

Restore from another server should bring up the saved game state of that server. GameUserSettings.ini should reflect this.

Actual behavior

Save state of the other server is not restored. Files have been copied and looks to be present. However, GameUserSettings.ini's reference to the save directory hash is incorrect.

Upon looking into the issue, we can see that the backup config file has indeed been copied. However, it gets modified shortly after.

Looking into the script a bit more, it looks like the container restarts after server shutdown command rcon-cli -c /home/steam/server/rcon.yaml "shutdown 1".

What appears to be happening is that the game shutdown might be writing to the config file upon shutdown. This likely means that in order for this to work, there would need to be two options:

1. rewrite the restore script as an external data restore tool
2. change how the container starts the palworld server such that palworld server shutdown does not affect the container's operation. This would allow the backup to be restored, and then the backup script should attempt to start palworld server again.

OS information

• OS: Ubuntu 22.04.2
• Palworld Version: 0.1.4.1
• Docker Image Version: sha256:4ed9eef7213960d03e752d8f65c75f22e69e54a6353da3fa01d0326b2450b1c3

Hardware information

• CPU: i7-13700k (source server), i3-2500T (test server)
• Memory: 32GB

docker-compose.yml contents

I'm using ansible. It's pretty easy to read so I hope no one minds if I just paste it instead of writing as docker-compose.

- name: Setup Service - Palworld Server (docker)
  community.docker.docker_container:
    name: palworld-server
    hostname: "{{ ansible_hostname }}"
    image: thijsvanloef/palworld-server-docker:latest
    pull: true
    ports:
      - 8211:8211/udp
      - 27015:27015/udp
    volumes:
      - "{{ palworld_data_dir }}:/palworld"
    restart_policy: unless-stopped
    env:
      TZ: "America/Toronto"
      PUID: '997'
      PGID: '997'
      PORT: '8211'
      PLAYERS: "{{ palworld_setting_players }}"
      SERVER_PASSWORD: "{{ palworld_server_password }}"
      MULTITHREADING: 'true'
      RCON_ENABLED: 'true'
      RCON_PORT: '25575'
      ADMIN_PASSWORD: "{{ palworld_admin_password }}"
      COMMUNITY: 'false'
      SERVER_NAME: "{{ palworld_setting_server_name }}"
    cgroup_parent: "{{ palworld_cgroups_parent }}"
    cpuset_cpus: "{{ palworld_cpuset_cpus }}"
    memory: "{{ palworld_memory }}"
    memory_swappiness: "{{ palworld_memory_swappiness }}"

Container/Host Logs

I haven't had time to review if it has any sensitive information so will refrain from uploading. However, based on what I've seen, I don't think it's necessary for troubleshooting.

[Phelms215]

Probably best to fix this by creating a flag and restarting the container. Doing the actual restore on the reboot before the server starts.

[ericxw]

That makes sense. Probably cleaner than what I suggested. Maybe keep all the steps before user warning/confirmation and the remaining steps can be done between shutdown and startup?

…

On Sun, Feb 11, 2024, 12:30 AM Patrick Helms ***@***.***> wrote: Probably best to fix this by creating a flag and restarting the container. Doing the actual restore on the reboot before the server starts. — Reply to this email directly, view it on GitHub <#359 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASFAZXIZN4AJJMDUCVB5D3YTBJQ5AVCNFSM6AAAAABDDH3F7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGQZTINBVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>