Configuring CoreProtect for Block Logging (Step by Step)
CoreProtect stands as an essential data logging and anti-griefing solution for Minecraft server administrators. Its design prioritizes speed and efficiency, ensuring minimal impact on server performance while providing comprehensive oversight of in-game activities. This powerful plugin records a wide array of actions, making it an indispensable tool for maintaining a secure and stable server environment.
![]()
CoreProtect logs critical events such as block placement and removal, interactions with chests and other containers, entity deaths, chat messages, commands used by players, and player logins and logouts. This extensive logging capability empowers server administrators to meticulously track who made specific changes, effectively rollback unwanted grief or damage, and restore affected areas to a previous, unblemished state. Given its thoroughness, CoreProtect can accumulate a significant amount of data, potentially exceeding 25 GB on servers that operate for extended periods. To manage this substantial data efficiently, the plugin supports storing information in a MySQL database, which offers improved performance and external management capabilities. By default, if a MySQL database is not configured, CoreProtect will utilize MySQLite for data storage.
Interacting with CoreProtect primarily involves using in-game commands, all prefixed with /co. Key commands include /co inspect for quickly checking the history of a specific block, /co lookup for performing detailed searches within the logs, /co rollback to undo actions, /co restore to revert any previous rollbacks, and /co purge for clearing out old, unnecessary data.
Step-by-Step Configuration for Block Logging
Setting up CoreProtect for effective block logging involves a series of straightforward steps:
- Download CoreProtect: The first step is to obtain the CoreProtect plugin’s
.jarfile. This should be downloaded from an official source, such as SpigotMC or Modrinth. It is crucial to ensure that the downloaded version of the plugin is compatible with your Minecraft server’s current version. - Upload to Server: Once the
.jarfile is downloaded, transfer it into your Minecraft server’spluginsfolder. This process can typically be completed using your server host’s control panel, which often provides a file manager, or by employing an FTP/SFTP client for direct file transfer. - Restart Server: After placing the plugin file in the correct directory, you must restart your Minecraft server. This action allows the server to properly load and initialize the CoreProtect plugin, making it active and ready for configuration.
- Optional: Configure MySQL Database: For larger or long-running servers, configuring CoreProtect to use a MySQL database is highly recommended for optimal performance and data management.
- Begin by creating a MySQL database through your server host’s control panel.
- Next, access your server files and navigate to the CoreProtect configuration file located at
plugins/CoreProtect/config.yml. - Edit this
config.ymlfile to include your newly created MySQL database credentials, such as the host, port, database name, username, and password. - After saving your changes to the configuration file, restart your server once more to apply the MySQL database settings.
- Verify Installation: To confirm that CoreProtect has been installed and configured correctly, once your server is back online, use the in-game command
/co status. This command will display the plugin version and indicate whether it is currently using MySQL or MySQLite for data storage. Additionally, you can use the/pluginscommand to verify that CoreProtect is listed among the active plugins.
Important Tips for Optimal CoreProtect Usage
To maximize CoreProtect’s effectiveness and maintain server performance, consider the following tips:
- Utilize MySQL: For any server expecting a significant amount of activity or planning for long-term operation, configuring CoreProtect with a MySQL database is strongly advised. This setup is crucial for efficiently managing the substantial volume of logged data and preventing potential performance issues that can arise from a rapidly growing local database file.
- Per-World Configuration: CoreProtect allows for specific logging settings to be applied to individual worlds. To implement this, copy the main
config.ymlfile and rename it to reflect the world’s name (e.g.,world_nether.yml). You can then adjust the desired logging options within this new, world-specific configuration file. - Blacklist Specific Logging: To prevent CoreProtect from logging certain actions, users, commands, blocks, or entities, create a file named
blacklist.txtwithin the CoreProtect plugin directory. Each item you wish to blacklist, such asminecraft:stonefor a block or#creeperfor an entity, should be placed on a new line in this file. This helps refine what data is stored. - Inspect and Lookup Commands:
- The
/co inspect(or/co i) command is invaluable for quickly checking the history of a block. Simply use this command and then left-click on the block in question to view its past interactions. - For more detailed and targeted log searches, employ the
/co lookupcommand. This command supports various parameters, includingu:(user),t:(time),r:(radius),a:(action),b:(block),i:(include), ande:(exclude), allowing you to pinpoint specific events within the extensive logs.
- The
- Regular Purging: CoreProtect’s database can grow very large over time. To reclaim disk space and maintain database efficiency, regularly schedule or manually execute the
/co purgecommand. This command removes old log data that is no longer needed. It is generally recommended to retain at least 30 days of data for historical purposes. - Refine Logging in
config.yml: Within theconfig.ymlfile, you have the option to disable logging for specific, less critical actions. For instance, you can choose to stop logging vine or mushroom growth. While this might slightly limit the comprehensiveness of your logs, it significantly helps in reducing the overall data volume, especially if disk space is a concern. - Optimize
natural-break: Consider disablingnatural-break: truein the configuration file if your server does not require logging blocks that fall off other blocks, such as torches. Disabling this setting can lead to an improvement in performance, particularly when CoreProtect is using a flat-file database (MySQLite).
Common Mistakes to Avoid
To ensure smooth operation and prevent potential issues with CoreProtect, be aware of these common pitfalls:
- Neglecting MySQL setup for large servers: A frequent mistake is failing to configure CoreProtect with a MySQL database on larger servers. This oversight can lead to a rapidly expanding local database file, resulting in performance bottlenecks for the server and consuming an excessive amount of disk space.
- Improper
config.ymlmodifications: Incorrect syntax or invalid entries within theconfig.ymlfile can prevent CoreProtect from functioning as intended. Always exercise caution and ensure the accuracy of any edits made to this critical configuration file. - Forgetting to restart the server: Any configuration changes made to CoreProtect, as well as the initial plugin installation, require a server restart (or the use of the
/co reloadcommand if available and supported) to be fully applied and take effect. - Executing broad rollbacks: Performing a
/co rollbackcommand without specifying precise parameters for user, time, or radius can lead to unintended widespread changes across the server. Always define these parameters to ensure rollbacks are precise and only affect the targeted area or actions. Some sources also suggest limiting staff access to the/co rollbackcommand due to its potential for misuse. - Ignoring database growth: Allowing the CoreProtect database to grow indefinitely without regular purging is a significant mistake. This will inevitably lead to massive storage consumption and can cause a noticeable degradation in server performance over time. Proactive purging is key to maintaining a healthy database.