The danger with any backup not based on direct disk snapshots is that files will be captured at different times. You can’t know what changed and while that might be fixable or not relevant in some cases, it can lead to broken save games in other cases.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
https://restic.net/
This is what I’d suggest for backups. Good performance, has versioning, etc.
The danger with any backup not based on direct disk snapshots is that files will be captured at different times. You can’t know what changed and while that might be fixable or not relevant in some cases, it can lead to broken save games in other cases.
Kinda depends where you have them hosted/what you are using to host them, but proxmox has a VM snapshot function that I like
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.
https://lemmy.world/post/1034668