ludusavi
ludusavi copied to clipboard
mtkennerly
Support for backups on 7zip
First of all thanks for the software, i am using with playnite and is really impressive. You could please could add support to make backups compressed? i think is better for backups on the cloud becase some problems on multiple folders tree or folder names and for share saves easily. could be something like "gamename/gamename.7z"
Thanks.
Glad you like it :D I think this would make sense to add, maybe in conjunction with an option to keep the last N different backups for each game. However, I would prefer to do it with regular zips (using bzip2 compression) since they have broader support, even though 7z + LZMA has better compression.
Out of curiosity, what sorts of problems have you seen in cloud backups with nested folders? At least for me, that has worked fine with the Google Drive sync client, but I don't know how other clients compare.
maybe in conjunction with an option to keep the last N different backups
I was about to suggest this. Having automatic backups is great, but it can be an issue when used automatically with Playnite since if something goes wrong with your save, it crashes and closes, Ludusavi will replace your previously working file with the failing one. Only downside I see is that Ludusavi would be replacing and uploading all the files again since it's a single file now, which wouldn't take advantage of https://github.com/mtkennerly/ludusavi/issues/31
Yeah, if a game has a big zip, then the whole thing would be reuploaded even if just one file inside changed. Still, I should be able to examine each game's zip and check if there are changes, so at least it wouldn't reupload zips unnecessarily.
How goes this and conjunction with an option to keep the last N different backups for each game.? This is really the only thing stopping me from using ludusavi sadly (currently using Game Save manager).
@JourneyOver I haven't gotten a chance to work on this feature yet, but it's definitely still planned. I'd like to have this for the next release, although I don't have a date in mind for that just yet.
Well I'm glad it's at least still planned, and I will more than likely end up switching over once it is implemented as GSM as an application hasn't really had an update in ages and db updates tend to be kinda slow.
@JourneyOver Have you considered trying Game Backup Monitor? It's still being developed, and currently supports 7z and multi-version backups. Might tide you over until Ludusavi implements the same?
@Darthagnon yea I have tried it and I didn't really like it, which is one reason why I have stuck with GSM for so long.
For context, the game Noita for example will update around 2000 files when saving, and I sync my saves to Drive, and it then takes a while to upload, just because of the number of files.
Any word on this perhaps @mtkennerly Still about the only issue that is stopping me from using this tool :/
@JourneyOver Sorry, I've been a bit slower recently with my open source work, but this is still absolutely something I plan to add. I'm afraid I don't have an ETA right now, though.
However, I would prefer to do it with regular zips (using bzip2 compression) since they have broader support, even though 7z + LZMA has better compression.
Why not allow user to configure the compression algorithm used? After all, use cases are varying.
I agree however that zip would be more widely acceptable, but isn't gzip more popular/lighter? When it comes to the size though, LZMA/LZMA2 indeed takes the crown when it comes to pure output size (.xz is the most popular extension on Linux, but less on other platforms), though it takes a lot of time to compress and some time to decompress too, so recently ZSTD started to shine in that matter. I don't see problem with people using any other tool such az lizard, LZOP, LZ4 or whatever, ideally with configurable compressor option (not sure how much trouble it's code wise, but they all have command line tools so just allowing advanced user to input any command line would suffice).
Those are fair points! I'm not opposed to adding other options, but that would likely be the first one I'd add, partly based on what has the best support in Rust libraries. For example, the zip crate supports bzip2, but not gzip. The situation may have changed since my other comment, though.
Nothing new to share at this time, I'm afraid. I'll update this ticket when that changes.
Yeah, if a game has a big zip, then the whole thing would be reuploaded even if just one file inside changed. Still, I should be able to examine each game's zip and check if there are changes, so at least it wouldn't reupload zips unnecessarily.
Sorry for bumping an old issue but IMO this could be easily solved creating incremental backups instead only full backups. Other backup programs have the rule of "x full backups + x incremental backups", and so when you want to restore the last backup you have to restore the last full backup + all the incremental backups after it.
For example, 1 full backup + 5 incremental backups, so if you want to restore it you have to restore first the full backup and then incremental backup 1, 2, 3, 4 and finally 5.
This could be made automatically by the program so the user doesn't have any harassment on decompressing x files instead only one.
Just noticed that Baldur's Gate 3 backup contains two duplicate sets of saves. One from the Steam cloud dir, and another from AppData/Local. The usual compression formats are pretty useless in this case. I guess the ~50% compression ratio can still be achieved via https://wimlib.net/
wimlib fully supports the file contents deduplication or "Single Instance Storage" which is built into the WIM format. Each distinct file contents is identified by its SHA-1 message digest and is stored only once in a given WIM archive.
