If you back them up while they are running you will be in for a lot of tears if you ever decide to restore one of the backups.
Data on disk is not stable while a program that uses it is running. While you are copying the data, the program might write new data alongside it and you never catch all of it. That will result in a corrupted backup!
You can take atomic snapshots with btrfs, zfs and the likes. Those will not suffer from the problem above and represent a “true” and exact point in time. But that still doesn’t solve your problem! The game might still have outstanding writes that you did not capture or the data on disk during operation is unstable by it self. Often programs only write out a stable “savegame” when you stop them entirely. Many games/programs try to detect such a “dirty” state on startup and will (correctly) refuse to run with your snapshot!
Unless your very game was explicitly made for inflight backups and has documentation on this, you are out of luck. Just shut it down, take a snapshot (needs no time, is instant) and start it up again. Then you have all the time in the world to make a backup of the snapshot you created and to transfer it elsewhere.
If you have no snapshot support (ext4 filesystem for example), you need to keep the game server stopped while you make a full copy.
That depends. Some applications and backups are aware of each other, and the application can quiesce to provide the backup a snapshot that won’t be modified while it’s being read. Sometimes this is done at the filesystem level too. For a VM, capturing the running state accomplishes the same thing (though the server may be surprised when a restore happens and suddenly all the clients are gone).
Bottom line, it depends on the server architecture.
If you back them up while they are running you will be in for a lot of tears if you ever decide to restore one of the backups.
Data on disk is not stable while a program that uses it is running. While you are copying the data, the program might write new data alongside it and you never catch all of it. That will result in a corrupted backup!
You can take atomic snapshots with btrfs, zfs and the likes. Those will not suffer from the problem above and represent a “true” and exact point in time. But that still doesn’t solve your problem! The game might still have outstanding writes that you did not capture or the data on disk during operation is unstable by it self. Often programs only write out a stable “savegame” when you stop them entirely. Many games/programs try to detect such a “dirty” state on startup and will (correctly) refuse to run with your snapshot!
Unless your very game was explicitly made for inflight backups and has documentation on this, you are out of luck. Just shut it down, take a snapshot (needs no time, is instant) and start it up again. Then you have all the time in the world to make a backup of the snapshot you created and to transfer it elsewhere.
If you have no snapshot support (ext4 filesystem for example), you need to keep the game server stopped while you make a full copy.
That depends. Some applications and backups are aware of each other, and the application can quiesce to provide the backup a snapshot that won’t be modified while it’s being read. Sometimes this is done at the filesystem level too. For a VM, capturing the running state accomplishes the same thing (though the server may be surprised when a restore happens and suddenly all the clients are gone).
Bottom line, it depends on the server architecture.