Class LiveWorldBackup

Namespace

McServerLauncher.Services

Assembly

McServerLauncher.dll

Backs up the world of a server that is running, by asking Minecraft to let go of it first.

public static class LiveWorldBackup

Inheritance

object

LiveWorldBackup

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

Zipping a world the JVM is writing to gives a torn copy: some region files from before a save and some from after, which is exactly the backup that looks fine until the day it is needed. The way round it is the one every server host uses — stop saving, flush what is pending, wait for the server to say it is done, copy, start saving again:

save-off
save-all flush
(wait for "Saved the game")
zip
save-on

save-on is in a finally, and that is the whole reason this is a separate class with its commands handed in: it can be tested that the server is never left with saving switched off. A backup that fails is an annoyance; a server that silently stops saving until somebody restarts it loses everything played in between.

Fields

SaveTimeout

How long to wait for the server to confirm the flush before copying anyway.

public static readonly TimeSpan SaveTimeout

Field Value

TimeSpan

Methods

RunAsync(WorldBackupService, ServerConfig, string, Action<string>, Func<TimeSpan, Task<bool>>, IProgress<string>?, CancellationToken)

Runs the sequence above and returns the new zip's path, or null if there was nothing to copy.

public static Task<string?> RunAsync(WorldBackupService service, ServerConfig config, string trigger, Action<string> sendCommand, Func<TimeSpan, Task<bool>> waitForSave, IProgress<string>? log = null, CancellationToken ct = default)

Parameters

service WorldBackupService

Does the zipping and the pruning once the world is safe to read.

config ServerConfig

The server whose world is being copied.

trigger string

Why this backup is being made; it ends up in the file's name.

sendCommand Action<string>

Writes a line to the server's console.

waitForSave Func<TimeSpan, Task<bool>>

Starts listening for the server's confirmation and returns the wait as a task. It is called before the flush command is sent, and awaited after: a small world can answer in the time between the two, and a listener started afterwards would miss it and wait out the whole timeout for a save that already happened.

log IProgress<string>

Where the steps are reported, which is the server's own console.

ct CancellationToken

Cancels the copy. save-on is still sent.

Returns

Task<string>