Bukkit, CraftBukkit, Spigot & BungeeCord 1.14.4 Development Builds

Discussion in 'News and Announcements' started by md_5, Apr 23, 2019.

  1. Shaggy67


    I've been running/upgrading a minecraft server for many years. I have never seen that happen. What hosting provider are you using? Is this the first time you have done an upgrade using their service?
  2. SlimeDog


    I run Linux on dedicated hardware. I've been updating Spigot and bleeding-edge plugins (ie., dev builds of everything) for over 5 years now. What you describe has never occurred. Just another reference point.

    Perhaps your provider has backups, if you don't have your own.
  3. Good work! Looking forward to the final release
  4. Safe to assume that other than the normal incremental bug fixes that this IS the final release. 1.14.4 is the default build and has been since August. Now, when 1.15 comes out... different story...
    • Agree Agree x 2
  5. Unless he's referring to this release as the last one he ever uses :D
  6. Messed up on so many levels.

    In over 3 years Spigot has never "deleted" anything IF you are using the Build-Tools directly from the Spigot Site and following their directions.

    Who in their right mind would not backup regularly?? If you truly lost everything I'd say you deserved it and I don't usually subscribe to beating people up on these forums as some love to do. But no backups is a total lack of common sense. Wow.

    Are you sure you're in the right folder? Theoretically you should be but now I have to ask. You put Build-Tools in your server directory and ran it there using Git? If not your old server will be were-ever you left it.

    Lastly why would you not at the least build yourself a new server in a new directory, copy over all plugins and maps to test in "Pre-Production" in case of problems? At least then you'd have a backup of sorts.
    • Agree Agree x 2
  7. SlimeDog


    Backups? Testing? What? :)
    • Funny Funny x 1
  8. I think he gets the point lol you guys are gonna kill him
    I file dumb bug reports all the time, don't make me post my blooper reel :p
    • Agree Agree x 1
  9. What you almost certainly read was that Spigot will replace it's OWN files with the new build. It will NOT bother files that do not belong to the build. I will as an example replace apache-maven files because they come with Spigot and they may have changed. Your maps on the other hand are yours and while Spigot will corrupt them if MOJANG changes the format as happened for 1.13, that is still your fault because you as a server owner need to be aware of such things. It's why we pay taxes to send you to skool to lern to weed... so you can read instructions when you need to. I'm sorry to be a smart A^& but this is common sense. Learn from this, buy a nice big USB stick, back up maps before you update your server and here's a novel idea: backup before starting any major renovation on a map in case it goes south and you want to revert. Had you done either of these these thread would never have been started. I do a development server build to check that my maps and plugins will be OK.
    Once I solve any issues there I build the Production server. All it takes is a different folder, port number and set the IP to localhost for the Development server. You can run them both at the same time and not bother the live server. Always Test.
    • Agree Agree x 1
  10. yeah, we all get it, but umm, it helps to check your post, so as not to feel such a fool.
    ... or was that intentional?
  11. It was quite intentional. I'm a Business Analyst so my spelling is fine when I want it to be.
    • Like Like x 1
  12. Perhaps a good question then, for posterity (and to help others learn best practices): How do YOU back up YOUR server?

    I regularly rsync the entire spigot directory (including world) to an external backup disk, and periodically export a static backup of just the world folder to a second computer (e.g. before a major upgrade, so I can restore specific chunks to pre-update state if needed).

    I have a second SSD on hand, same capacity as the original in the server, keep meaning to set it up as a mirror so that if the disk dies on me I can just switch to the other disk when needed. Right now it's blank, so worst case I'd need to do a fresh OS install then rsync in the latest backup to restore things. For a barebones headless Debian install that won't take long.
  13. I have a WinSCP FTP script which I run on a more-or-less daily basis that downloads all the modified files and ZIPs them up. I save the ZIP files for two weeks, except the first backup every month gets saved for a year. These also get backed up by Carbonite and on a external hard drive.

    I really like this system, because you end up with a collection of ZIP files, each one containing a copy of the server at the given time. And ZIP files are easier to handle than a bunch of separate files. For example, you could copy a ZIP file to off-site storage. One file, and you've got it all.

    Details https://www.spigotmc.org/threads/regular-backups-using-ftp.346864/#post-3219653
  14. I'm currently on shared hosting (ExtraVM), the host of course take their own backups for disaster recovery/hardware failure events. Every 48h I have a backup taken of my server folder, zipped up and sent to my SFTP account w/ SecureDragon. At least once a month I download one of these to my personal computer. I'd do it more often but I only have 25Mbps down and my world is 29GB compressed.
  15. SlimeDog


    I have a (custom) Linux script, automated by cron, that (g)zips up (and timestamps the zip filename) the entire primary server and secondary server every hour, then copies the primary zip to the secondary server. Once a week, I copy the primary zip to a third device. I keep the zips for three days on the primary and secondary servers, and keep the weekly offsite zips for a few months. I stage plugin updates to occur immediately after verified primary backups. These practices allow me to recover easily should anything cause problems, and is sufficient regimen for test servers, IMHO. When the servers were production, I copied primary to secondary more frequently. Note that my servers never crash; if they did, I would consider more frequent backups.
  16. This would have made for a good, but seperate thread (topic), which could reach more viewers.

    I was taught to use the Grand-Parents, Parents, and Children method using Filezilla.
    Where the Children are saves of the 'differences' between the latest Parent and their elder Children.
    (This makes for smaller regular downloads).
    IE Grand-Parents are weekly, Parents are daily, and Children are hourly.
    (Or, whatever time seperated periods you wish to choose.)

    Of course, you can allways keep Great-Grand-Parents for nostalga :D
  17. SlimeDog


    The main problems I have with diff-based strategies:
    1. Diffs consume a lot of CPU, exactly what one typically doesn't have to spare on a MC server, especially a hosted virtual machine. Think: lag. Alternatively, a date-based strategy is very fast, but see (2). (Zip-based strategies also consume CPU, but in my experience, not as much.)
    2. The logic is more prone to error. If the process misses a Child file, the recovery is not accurate. (With a full-backup strategy, just process everything.)
    3. If a Grandparent or Parent is corrupted, either in creation or in transit between machines, diffs based on them cannot reconstruct the full recovery set. (If a full backup is corrupted, you just go back another hour (or whatever your periodicity is.)
  18. Curious - necessary to stop server before running the cron job? I always stop prior to backup, but this is a small in-home server so I can safely verify no one is playing when I stop it. And with a fast system/fast SSD, stopping, backing up, and building latest version of Spigot doesn't take more than a few minutes, most days.
  19. SlimeDog


    I do not stop the server for backups, but my population is very small. I have never discovered a corrupted backup, and I restore from backup (on the secondary server) every few days, which is way more exercise of a backup/restore process than anyone else is likely to have done.

    As for building Spigot and updating plugins (and I run all bleeding edge dev versions, so it's a deluge every day), I do that on the secondary server, check that everything is alright, and update the primary server with the new configuration and JAR files when I feel the need. The entire primary shutdown/update/start-up process (once I have everything ready to go) takes less than 5 minutes, average 3 minutes down time.
    #1699 SlimeDog, Oct 30, 2019
    Last edited: Oct 30, 2019
  20. Shaggy67


    I tar the directory tree, gzip, and then copy it over to an external RAID array. Normally only when upgrading.