• Minecraft version: 1.12.2
• Forge version: forge-1.12.2-14.23.5.2838-universal
• Modpack version (links to current modlist): 1.7.3
• Mod versions: Backups-1.12.2-1.4.7 (from CurseForge)

On the main mod page it says that the mod takes incremental backups, which means that only files that have been changed get backed up, right?

Well, for whatever reason, my client seems to be taking a full backup every 15 minutes. All the files and filesizes seem to be the same, even for the dimensions that I don't have loaded.

Just to double check, I flew around my world in singleplayer for a while to generate a bunch of chunks, then compared the folder filesize to its previous value. I took a backup, then exited the client to be sure those chunks were no longer loaded, and when I signed back in, it took another backup. Both were the same size (101mb, compared to the 94.3 that the other 6 were).

Perhaps I'm just misunderstanding how this is meant to work?

Thanks in advance for your help.

So, I'll be completely honest, I couldn't quite compute what that wiki article said, so perhaps this shall be obvious to you. However, I've had to remove the mod because it ran me out of disk space. I started with 36/110gb used as of yesterday, and then today the most recent backup refused to take because the disk was full.

[20:05:02] [Backup Thread/ERROR] [backups]: Backup failed
java.io.IOException: No space left on device

It then failed to even produce a Sampler stall report for the same reason. Here's the last thing printed in my console log (wasn't able to print to the latest.log): https://pastebin.com/UFuWSqGL

I had set my config in such a way that it was keeping the least amount of backups possible, and only backing up every 30 minutes instead of every 15: https://pastebin.com/pP6iJgs4

Judging by my backups file, that seems to have been respected:

My world file is about 5gb zipped. Assuming these have a similar compression rate, the math checks out: 5gb a piece would definitely use up the rest of the disk space. Whether the backups were actually taking up that much space, the server seems to think they did, and threw an absolute fit the last time it started. Perhaps I'm missing something obvious?

Hmm that may be a bug. Try downloading this jar file, uncompressing it and running it like this:

java -jar <path to jar file> <path to backups directory>

It will tell you the size of the each backup and the total size of all backups. Here's the source code for it if you want to make sure I'm not trying to install malware on your computer. If you really don't trust me then you can decompile it.

It should give you an output like this:

Size of 1-4-2018 11-26-00 AM is 29,044,242
Size of 1-9-2019 4-54-03 PM is 30,632,501
Size of 10-3-2018 11-35-00 AM is 1,446,762
Size of 10-9-2018 9-08-45 PM is 14,133,527
Size of 11-10-2018 8-58-42 PM is 3,076,237
Size of 11-7-2019 12-48-58 PM is 12,886,433
Size of 12-1-2018 10-19-00 PM is 12,852,398
Size of 12-6-2018 8-49-39 PM is 14,010,029
Size of 12-8-2018 3-43-42 PM is 2,050,539
Size of 14-4-2018 8-23-00 PM is 14,336,562
Size of 14-8-2019 2-35-36 PM is 2,047,621
Size of 16-2-2019 9-54-31 PM is 3,324,994
Size of 16-5-2018 8-59-37 PM is 14,556,920
Size of 17-1-2018 6-22-00 PM is 7,807,714
Size of 17-4-2018 3-33-00 PM is 2,059,957
Size of 17-7-2019 4-38-38 PM is 1,010,807
Size of 2-10-2018 9-32-34 PM is 1,451,009
Size of 2-5-2018 3-52-00 PM is 9,035,154
Size of 21-2-2019 9-45-50 PM is 2,036,061
Size of 21-6-2019 12-37-44 PM is 2,753,462
Size of 22-12-2018 11-15-13 AM is 2,556,377
Size of 23-1-2019 7-20-08 PM is 1,674,359
Size of 24-8-2018 11-47-07 AM is 7,852,402
Size of 25-3-2019 10-36-58 PM is 1,630,462
Size of 26-2-2018 10-47-00 AM is 2,748,954
Size of 26-8-2019 3-25-53 PM is 1,276,558
Size of 26-9-2018 11-41-35 AM is 1,083,274
Size of 27-5-2018 5-54-31 PM is 1,703,313
Size of 27-7-2019 12-11-13 PM is 7,973,022
Size of 28-4-2019 6-46-17 PM is 1,634,625
Size of 28-6-2019 4-42-09 PM is 1,677,602
Size of 28-9-2019 1-47-28 PM is 1,645,061
Size of 28-9-2019 10-23-00 AM is 1,496,700
Size of 29-5-2018 11-16-00 AM is 1,701,789
Size of 3-9-2018 1-02-32 PM is 1,631,058
Size of 30-12-2018 10-50-55 AM is 2,562,942
Size of 30-7-2018 12-28-42 PM is 1,633,560
Size of 31-1-2019 1-57-46 PM is 999,597
Size of 31-5-2019 3-29-30 PM is 792,435
Size of 4-1-2019 12-24-50 PM is 1,628,589
Size of 4-2-2018 11-27-00 PM is 2,037,841
Size of 5-4-2019 9-40-54 PM is 1,632,232
Size of 6-6-2018 1-11-25 PM is 1,273,354
Size of 6-7-2018 2-55-56 PM is 2,049,501
Size of 7-1-2018 4-29-00 PM is 3,166,259
Size of 7-4-2018 8-12-00 PM is 1,449,058
Size of 7-7-2019 4-09-09 PM is 1,652,851
Size of 8-4-2015 10-42-05 AM is 4,377,072
Total size: 244,093,776
Number of files: 11,881
Number of unique files: 1,749

It lists the size of each backup, and at the end the total size, the total number of files and the number of unique files. Unique files should be much smaller than total files if incremental backups are working.

In singleplayer, everything checks out fine. The initial file is full sized, and all subsequent files are 0 (I just went afk with the game open). I tested this in two different saves - one with backups taken during my initial testing of the mod, and one that I created just to test it out this time.

My singleplayer instances are on a Windows machine, while my server is Ubuntu, but I doubt that's related. I'll try testing on my server for a short while and see if I can replicate it.

Okay, I left the mod running on my server for a while until storage said it was at 100/110gb. I then started downloading the backups - but there were over 20k files, so I ended up canceling the download and only getting the earliest and latest backups instead. They, and all the other files that downloaded before I canceled, looked correct via the jar you linked - It showed the first one as 10,830, and all the following ones as 0.

Which seems a little odd to me, because people were definitely on the server during the intervening time... Wouldn't those files show up as a little bit different in that case?

Can you post the exact output? None of the backups should have a size of zero, there might be something wrong with the program I gave you. Also what format are you downloading the backups in? If you're downloading them as a zip, or if you download each one separately, it'll destroy the hard links and the backups' size will become greatly inflated.

So here's the output from my local backups from my singleplayer worlds on my windows machine:

Size of 12-10-2019 1-48-31 PM is 463
Size of 12-10-2019 12-57-06 PM is 0
Size of 12-10-2019 2-03-34 PM is 0
Size of 12-10-2019 2-18-35 PM is 0
Size of 12-10-2019 2-33-38 PM is 0
Size of 9-10-2019 12-36-34 PM is 0
Size of 9-10-2019 3-53-25 PM is 0
Total size: 463
Number of files: 740
Number of unique files: 1

Size of 6-10-2019 6-45-00 PM is 4,140
Size of 6-10-2019 7-20-55 PM is 0
Size of 7-10-2019 3-49-03 PM is 0
Size of 7-10-2019 4-49-29 PM is 0
Size of 7-10-2019 5-52-56 PM is 0
Size of 7-10-2019 6-53-31 PM is 0
Size of 7-10-2019 7-38-53 PM is 0
Size of 7-10-2019 8-58-50 PM is 0
Size of 7-10-2019 9-44-12 PM is 0
Size of 8-10-2019 7-55-35 PM is 0
Total size: 4,140
Number of files: 2,460
Number of unique files: 1

As to what format I was downloading the server backups in - I was just downloading them directly from the folder via FTP, so they were downloading as .gz files. It's very probable that the hardlinks were broken, since it's a pretty imperfect method of downloading them. I could theoretically SSH in and execute the jar? But I'm terrible with linux in general and headless java is very intimidating to me, haha. I do all my server management via FTP and Pterodactyl panel, aside from when something major goes wrong.

Thanks for the response! I'm hesitant to try to replicate the issue on my live server again, but I'll test this out in singleplayer and see if the issue occurs there as well. I'll get back to you once I have something to report. :)

I did some testing and apparently the jar I gave you doesn't work on windows. BasicFileAttributes.fileKey returns null on windows, which means that the jar I gave you thinks every single file is the same (because I'm comparing the file keys and null always equals null). That's why it says the number of unique files is one.

I think the only way you're going to get proper results is if you run the jar I gave you on the machine the server's running on.

Ah, I see.

So, in full disclosure, we've figured something else out for our server backups. The main feature I was looking for was the ability to exclude certain dimensions from being backed up, and we found one that does that. So if you're just troubleshooting for my sake, then it's appreciated but unnecessary.

However, if you'd like me to test this again for the sake of completeness, I can do that. It may take me a while though, because life is a little crazy atm.

Let me know, and thanks for your time in any case! :)

Each backup only stores the files that have changed since the last backup. However this will not appear to be true if you just look at file sizes because most file explorers don't understand hard links, which I use it implement the incremental backups.

Hard links are just multiple names for the same file. So you could have file1 which is 20 bytes, and then create a hard link to it with the name file2. If you look at either file your system will say that it's file size is 20 bytes, and if you look at both together it'll say 40 bytes, but really they are the same file and only take up 20 bytes on the disk. Here's a link to wikipedia about hard links.

Each backup creates new files for all the files that changed since the last backup, and creates hard links to all the files that didn't change since the last backup. That way all files appear in each backup but the unchanged files don't take up extra space.

If you want to see the true size of your backups then click the backups button in the world selection menu after selecting a world to see all the backups and their actual file sizes.

Ah, okay. Thank you for the link! Is there a way of seeing actual filesize on a dedicated server? I'd assume not, but I figured I'd ask.

Not currently, but I'll try to add a way in the next update.

Understood. If you can find a way via command or something, that would be excellent! But I understand if not. Thanks very much!