# Import from CoreProtect > Bring your CoreProtect history into Oasis, step by step, and learn exactly what comes over, what doesn't, and why. Source: https://oasis-protection.com/docs/guides/importing/ If your server ran CoreProtect before Oasis, you don’t have to lose that history. `/oasis import coreprotect` reads your CoreProtect database and writes it into the Oasis history, so your staff can look it up and roll it back with the same commands they use for everything else. This page walks you through an import, then explains what comes over, what can’t, and how imported history behaves in lookups and rollbacks. Where something doesn’t come over, it tells you why. Almost always the reason is that CoreProtect never stored it. ## What an import does The import reads every CoreProtect table that holds edits (blocks, containers, items, chat, commands, sessions, signs and vehicle inventories), oldest row first. It turns each row into an Oasis edit and writes it into your history. A few things are worth knowing up front: * **It only reads.** Oasis opens the CoreProtect database read-only and never writes anything back to it. * **It runs in the background.** Oasis keeps logging while the import runs, and the import never gets in the way of the live log. * **The history gets it all at once.** The imported edits join the history when the import ends, so a lookup sees the whole import or none of it. * **It counts what it leaves out.** Every row that doesn’t come over is counted in the summary at the end, with the reason. * **It runs once.** After an import finishes, Oasis refuses to import CoreProtect again, so make the first run count. See [An import runs once](#an-import-runs-once). * **It never imports a row half right.** If CoreProtect kept only part of what a row changed, Oasis leaves the whole row out instead of guessing the rest. A rollback of a half-right row would put back something that never stood there. ## Before you start ### Run both plugins side by side You can install Oasis next to CoreProtect, run both for a while, and import later. CoreProtect can keep running, before and after the import. On DuckDB, this works when Oasis keeps its store embedded on Linux; see below. Oasis logs every edit from its first logged edit on. The import reads only the CoreProtect rows from before that edit. It leaves out the whole second of that edit. So each edit enters the history once: the older rows come from CoreProtect, and the newer rows come from Oasis’s own log. The preview names this time, for example `Oasis began logging at 2026-10-05 14:03:27 CEST`. The rows from that time on are already in Oasis, so the counts in the preview cover only the days before Oasis. If Oasis has logged no edit yet, the import reads the CoreProtect rows from before the start of the import. Oasis logs every edit from then on. **DuckDB:** A CoreProtect that runs on DuckDB holds its database file. On Linux with the embedded store, Oasis reads the file while CoreProtect runs, and keeps it open until the server stops so that CoreProtect keeps its lock. On Windows, or with Packs Server, Oasis cannot read the file while CoreProtect runs, and the preview says: `CoreProtect runs on DuckDB and holds its database file. Stop CoreProtect, then run /oasis import coreprotect again.` Stop CoreProtect, then run the import. You can run both plugins side by side until then: the import reads only the rows from before Oasis’s first logged edit. Leave the `plugins/CoreProtect` folder where it is. When CoreProtect isn’t installed, Oasis looks for its settings in `plugins/CoreProtect/config.yml`, next to the Oasis folder. ### Make a backup The import doesn’t change the CoreProtect database, but back up `plugins/Oasis/store` (or the store on Packs Server) before a big import anyway. If you don’t like the result, a backup is the quickest way back. ### Check the disk Every row that comes over becomes an edit in your history, and each row CoreProtect rolled back brings one more edit. The preview tells you how many rows there are, so make sure the disk has room for a history that size before you start. The **Storage** line in `/oasis status` grows while the import runs. ### Which databases it reads Oasis reads CoreProtect on all four of its database engines: **MySQL**, **SQLite**, **DuckDB** and **ClickHouse**. You don’t pick one. Oasis takes the engine and the connection details from CoreProtect’s own `config.yml`, the same way CoreProtect reads them. If your server ran Minecraft before 1.13, CoreProtect’s old block names still come over, because Oasis maps them to the modern names. ### Run the latest CoreProtect once first We strongly recommend that you upgrade CoreProtect to a build of its latest source code before you import, and start your server with it once. Oasis follows CoreProtect’s `master` branch on GitHub, not its numbered releases. Each time CoreProtect starts, it upgrades its own database: it adds new columns, fixes old rows, and applies its bug fixes. A database that a current CoreProtect has upgraded is the database Oasis reads best. 1. Build CoreProtect from the `master` branch of [PlayPro/CoreProtect](https://github.com/PlayPro/CoreProtect), or use the newest build you can get. 2. Put that jar in `plugins` in place of your old CoreProtect, and start the server. 3. Wait until the console says CoreProtect is enabled, then stop the server. CoreProtect has now upgraded its database. 4. Put Oasis in `plugins`, start the server, and run the import. CoreProtect can stay in `plugins`. ### Which CoreProtect versions Oasis reads CoreProtect’s numbered releases don’t map cleanly onto its source code, so Oasis names its support by CoreProtect’s own database version. CoreProtect writes that version into its `version` table. | Your database | What happens | | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Database version 2.22 or later: written or upgraded by any CoreProtect build from mid-2023 on, release or `master` | Oasis imports it. Oasis is tested against CoreProtect’s databases from 2025 on and against its current `master`. | | Older than database version 2.22 | Oasis refuses it at the preview and writes nothing: “This CoreProtect database is older than CoreProtect 2.22 (it records version …). Start it once with a current CoreProtect build so CoreProtect upgrades it, then import.” CoreProtect upgrades any database from version 2.0 on. | A few things an older database lacks, and how they come over: * **Player head skins.** CoreProtect stores skins from database version 2.23 on. Without one, a head comes over with its owner and no stored skin. * **Sign text that CoreProtect rolled back.** The latest CoreProtect builds can roll back sign text, and they mark it in a new column of the sign table. CoreProtect adds that column to an existing database only from version 25 on. Without the column, Oasis can’t tell which sign edits CoreProtect rolled back, so every sign edit comes over as it was logged. * **Vehicles and their inventories.** CoreProtect tracks these from mid-2026 on. An older database has none to bring. **ClickHouse:** CoreProtect’s ClickHouse storage is new, and CoreProtect can’t upgrade a ClickHouse database from its first builds of July and early August 2026. Run a current CoreProtect build on ClickHouse once before you import. Oasis refuses a ClickHouse database that is newer than the versions it knows, and says so. ### With Packs Server, the store does the reading The import runs inside the store, not in your Minecraft server. With [Packs Server](/docs/packs-server/setup/), Packs Server connects to CoreProtect’s database. That means: * a MySQL or ClickHouse host must be reachable **from the Packs Server machine**, so `127.0.0.1` means the Packs Server machine, not your Minecraft server; * a SQLite or DuckDB file must be at the **same path on the Packs Server machine**. With Packs Embedded, everything runs on your Minecraft server and none of this matters. ## Run the import You need the `oasis.import` permission. 1. **Start the preview.** ```plaintext /oasis import coreprotect ``` You can run it in game or from the console. 2. **Allow Oasis to read CoreProtect’s config.** Before it reads anything, Oasis asks: ```plaintext To import, Oasis reads the CoreProtect config at . That file can hold the password of the CoreProtect database. Is that okay? [yes, read it] [no] ``` The path is `config.yml` in CoreProtect’s plugin folder, or `plugins/CoreProtect/config.yml` when CoreProtect isn’t installed. Oasis needs that file for the database engine, the address, the login and the table prefix. Because the file holds the database password, Oasis asks every time. Click **\[yes, read it]**, and the preview goes on. Click **\[no]**, and Oasis tells you it read nothing and no import starts. In the console, type `/oasis import coreprotect confirm` to say yes. The question lasts two minutes. 3. **Read the preview.** Oasis connects to the database, counts the rows in each table, and tells you how many it would read. It also lists what comes over and what it leaves out. It names the time that Oasis began logging. Nothing is written yet. If the database doesn’t answer, you get one line with the reason, such as a wrong password or a missing file. See [Troubleshooting](#troubleshooting). 4. **Confirm.** In game, click **\[start the import]**. In the console, type the same command again: ```plaintext /oasis import coreprotect confirm ``` The confirmation lasts two minutes. After that, run the preview again. 5. **Watch it run.** Oasis prints `Importing CoreProtect on ...` and goes to work. The console gets a progress line every 30 seconds. See [While it runs](#while-it-runs). 6. **Read the summary.** When it’s done, you get a line like `Imported 12,000 rows from CoreProtect on SQLite at ... in 1 min.`, then one line per table. Each table line says how many rows came over and how many were left out, and why. The person who started the import sees it in chat, and the console always gets a copy. Only one import runs at a time. If you start another, Oasis tells you one is already running. ## While it runs `/oasis status` gets an extra line while an import runs: ```plaintext Import: CoreProtect on SQLite at plugins/CoreProtect/database.db · 12,000 rows in 1 min · 200 a second · in the history when it ends ``` It names the source, the rows written so far, how long the import has run, and its speed. The line counts rows, not edits: a row CoreProtect rolled back also brings a rollback edit with it (see [CoreProtect’s own rollbacks](#coreprotects-own-rollbacks)). The **Edits** line doesn’t include the import until it ends, because the imported edits join the history all at once. The **Storage** line does grow while it runs, because the files are already on disk. `/oasis import status` shows the same progress on its own: `Importing CoreProtect on ...: 6,000 rows in 1 min`. After the import ends, it shows the summary again. ## What comes over | CoreProtect logged | In Oasis | Notes | | -------------------------------------------------------------------- | --------------------------- | --------------------------------------------------------------- | | Blocks broken and placed | Block edits | With the block’s state, such as which way it faces. | | Block clicks (doors, buttons, levers) | Interaction edits | For lookups. | | Signs | Sign edits | The text on both sides, its colors, glow and wax. | | Banners | Block edits | With their patterns. | | Shulker boxes | Block edits | With the items inside, but not their slots. | | Player heads | Block edits | With the owner and the skin. | | Spawners | Block edits | With the mob they spawn. | | Items taken from and put in containers | Container edits | | | Boats and minecarts placed | Entity edits | | | Items moved in and out of chest and hopper minecarts and chest boats | Entity edits | | | Items dropped and picked up | Item edits | For lookups. | | Chat and commands | Chat and command edits | For lookups. | | Logins and logouts | Session edits | For lookups. | | What CoreProtect rolled back | The same edits, crossed out | See [CoreProtect’s own rollbacks](#coreprotects-own-rollbacks). | For every other block with a block entity (chests, furnaces, beds, beehives and the rest), the block comes over as a new block of that kind holds it. CoreProtect never kept their names, locks or other data, so there’s nothing more to bring. A chest’s items do come over, through its container rows. ## What doesn’t come over, and why Each of these is counted and left out. The summary line of each table tells you how many. | Not imported | Why | | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Mob kills | CoreProtect keeps a killed mob without its equipment, its potion effects or its health, so a rollback couldn’t bring it back as it was. | | Mobs spawned from eggs | The game picks a new mob’s variant and traits, and CoreProtect doesn’t keep them. | | Players killed by players | Oasis doesn’t log a player as an entity. CoreProtect’s own rollback skips these too. | | Command blocks | CoreProtect keeps only the command, not whether the block runs on its own. A rollback would put back a command block that behaves differently. | | Spawners placed by WorldEdit, and banners with no pattern data | Some ways of placing or breaking a block (WorldEdit, among others) keep none of its data in CoreProtect. Without it, Oasis can’t rebuild the block. | | Paintings, item frames and armor stands, and items put on them | Oasis has no edit for these that a rollback can put back. | | Items moved in and out of jukeboxes, lecterns, chiseled bookshelves, decorated pots and shelves | These blocks hold their items, but they aren’t containers. An Oasis rollback writes items into containers only. | | Ender chest items | An ender chest belongs to a player, not to a block. A rollback has nowhere to write them. | | Items thrown, shot, broken, crafted, sold and bought | Oasis has no edit for these. For crafts and trades, CoreProtect logs the recipe, not the items. | | Clicks, shears and leashes on mobs | Oasis has no edit for these. CoreProtect stores no detail with them either. | | Vehicle inventories that CoreProtect didn’t follow from the start | If CoreProtect first saw the vehicle after it was placed, the starting contents are unknown, so Oasis can’t rebuild them. | | Rows with a block, item, mob, world or player this server doesn’t know | See below. | | Rows whose items don’t read back | The item data CoreProtect saved doesn’t load on this server. Oasis won’t guess the item, so it leaves the row out. | ### Item data CoreProtect silently drops Sometimes CoreProtect can’t save an item’s data, for example an item with a custom equip sound or a custom music disc song. CoreProtect then drops the part that failed, or all of the item’s data, and it doesn’t tell you. It warns only on its development builds. The database then holds no sign of the loss, so Oasis can’t see it either. Such an item comes over without the part CoreProtect dropped, or as a plain item with no name, enchantments or other data. A shulker box can come over with fewer items, or empty. These rows count as imported, because what CoreProtect kept reads back fine. ### Unknown names A row counts as **unknown** when it names something the current server doesn’t recognise: * **A block or item that Minecraft has since renamed or removed.** CoreProtect stores the name as it was when the row was logged. If your server no longer knows that name, the row can’t be rebuilt. Pre-1.13 names are the exception: Oasis maps those to the modern names. * **A mob type from an older server.** Older servers used some entity names that differ from today’s, such as `mushroom_cow`. * **A world CoreProtect has no record of, or a user row that’s missing.** * **A sign edit where no sign stands**, as far as the earlier rows show. If the block name is known but its saved state doesn’t fit this server (a property that no longer exists, for example), the row isn’t left out. The block comes in with its default state instead, so the block is right but may face a different way. ## Rolling back imported history An imported block edit is an ordinary Oasis edit. You can roll it back and restore it by player, time, area, block or cause, just like history Oasis logged itself. Oasis’s careful rollbacks work on it too: if someone repaired a block after the griefer, Oasis still keeps the repair. Some things differ, because CoreProtect stored less than Oasis does. ### No player behind lava, fire and the like When a player pours lava and it burns a house, Oasis normally knows who poured the lava, so one rollback of that player puts the house back. CoreProtect never stored that. It logs the burnt blocks under `#lava` or `#fire`, with no player behind them. So imported natural changes arrive under their cause, with no player. A rollback of the player who lit the fire doesn’t reach them. To undo that damage in imported history, roll back the cause in the area instead, for example `/rollback user #fire near 30 last 3d`. CoreProtect’s natural causes arrive like this: | CoreProtect | Oasis | | ------------------------------------------------------------------------------------------------------------------------- | -------------- | | `#fire` | `#fire` | | `#water`, `#flow` | `#water` | | `#lava` | `#lava` | | `#creeper` | `#creeper` | | `#explosion`, `#tnt`, `#wither`, `#enderdragon`, `#ghast`, `#end_crystal`, `#bed`, `#respawn_anchor` and the wind charges | `#explosion` | | `#decay` | `#decay` | | `#natural`, `#tree`, `#vine`, `#mushroom`, `#bamboo`, `#chorus`, `#amethyst`, `#sculk_catalyst`, `#bonemeal` | `#growth` | | `#piston` | `#piston` | | `#gravity` | `#falling` | | `#hopper` | `#hopper` | | `#dispenser`, `#dropper` | `#dispenser` | | `#worldedit`, `#we` | `#worldedit` | | any other `#` name | `#environment` | ### Block data is only what CoreProtect kept A rollback puts back what the edit holds. For a banner that’s its patterns. For a shulker box it’s its items, filled from the first slot on, which is how CoreProtect’s own rollback puts them back. For a head it’s the owner and skin, for a spawner its mob with default settings, and for a sign its text. Anything CoreProtect didn’t keep, such as a chest’s custom name, comes back as a new block holds it. ### Containers have no slots CoreProtect sums up several clicks into one change per item: how many went in, and how many came out. It doesn’t keep the slot. So an imported container edit names the item and the amount, but not where in the chest it was. ### Vehicles A rollback of an imported boat or minecart placement takes that exact vehicle out again, by its ID. A vehicle’s inventory is rebuilt from CoreProtect’s changes, so its slots are Oasis’s own arrangement. Oasis puts each item into the first stack of its kind with room, then the first empty slot. ### Item, chat and session edits are for lookups Drops, pickups, chat, commands, logins and block clicks are for lookups only, the same as when Oasis logs them itself. ### CoreProtect’s own rollbacks If CoreProtect had rolled back a row, the row comes over with a rollback edit on top, so lookups show it crossed out, just like an Oasis rollback. The block ends up as CoreProtect’s rollback left it. The same goes for sign text that CoreProtect rolled back. CoreProtect marks a sign rollback only in a database that has its new rollback column. See [Which CoreProtect versions Oasis reads](#which-coreprotect-versions-oasis-reads). There are two differences: * **`/undo` can’t reach it.** CoreProtect kept no record of the rollback as a whole, only a flag on each row. Oasis has nothing to undo. * **One case lands differently.** CoreProtect’s flags don’t say which rollback set them. Say one CoreProtect rollback covered two changes to a block, with a change it skipped in between. Oasis then writes two rollbacks, and the block ends up as the later one left it, which can differ from what CoreProtect left. An inventory rollback in CoreProtect gave a player their items back. It didn’t change the world, so those rows come over as they were. ### Times are to the second CoreProtect stores whole seconds, so imported edits do too. Within one second, Oasis keeps them in the order CoreProtect wrote them. For blocks and signs, CoreProtect stores the moment it saved the row, which can be a little after the change happened. ### Every row gets this server’s data version CoreProtect stores no Minecraft data version. Oasis gives each imported row the data version of your current server. After a Minecraft update, you can roll back imported edits like any other edit. ## Looking up imported history Imported edits show up in `/lookup` and in the inspector like any other edits, as soon as the import ends. Names come from CoreProtect. For a player, Oasis takes the UUID from CoreProtect’s user table, or from its username log by name. If CoreProtect never stored a UUID for a name, Oasis makes the offline-mode UUID from that name. On an online-mode server, those rows may not match the player’s real account in a lookup by name. ## Stopping and carrying on To stop an import: ```plaintext /oasis import cancel ``` Oasis stops after the rows it’s already working on. It keeps everything it wrote and remembers where it stopped. To carry on, run the preview and confirm again. The preview says how many rows are still to do, and the import continues from where it stopped. It doesn’t start over. The same goes for a failure, and for a server restart with Packs Embedded: a restart stops the import, and the preview and confirm pick it up again. With Packs Server, the import runs inside Packs Server and keeps its place while your Minecraft server restarts. It needs your Minecraft server to read CoreProtect’s items and blocks, so it waits for it. Once Oasis has opened the store again, the import goes on by itself, with no command. If the import ended while your Minecraft server was down, Oasis doesn’t announce it at startup. Run `/oasis import status` to see the summary. A server that’s killed mid-import can lose the last chunk of work that wasn’t saved yet. Those rows are read again from CoreProtect when you carry on, so nothing is skipped and nothing is written twice. ### An import runs once When an import finishes, the store keeps a record of it. After that, the preview reads no database and offers nothing. It says that CoreProtect was imported in full on that date and that Oasis doesn’t import it twice. A start is refused too. Without this record, a second run would read CoreProtect from the first row and write every row a second time. The record is kept under the word `coreprotect`, not under one database. So a second, different CoreProtect database is refused as well. `/oasis purge` deletes edits but keeps the record, and there’s no command to import again on purpose. The record lasts as long as the store. ## Troubleshooting **“CoreProtect has no config at …”** Oasis couldn’t find `config.yml`. Put CoreProtect’s folder at `plugins/CoreProtect`, or install CoreProtect and start the server once so it writes the file. **“database-type in … is …”** CoreProtect’s config names an engine Oasis doesn’t read. Oasis reads `mysql`, `sqlite`, `duckdb` and `clickhouse`. **“CoreProtect on … did not answer: …”** Oasis couldn’t connect. The rest of the line is the database’s own reason. Check the host, port, user and password in CoreProtect’s config. With Packs Server, check them from the Packs Server machine. **“CoreProtect runs on DuckDB and holds its database file”** CoreProtect on this server holds the file, and Oasis cannot read it beside CoreProtect here (Windows, or Packs Server). Stop CoreProtect, then run the import again. **“DuckDB will not open … while another program holds it open for writing”** Another program holds the file, for example a CoreProtect on another server. Stop that program, or import a copy of the file that it closed. **“… was imported in full on … Oasis does not import it twice.”** This store already holds a finished CoreProtect import. Oasis imports CoreProtect only once, whichever database it is. See [An import runs once](#an-import-runs-once). **“Oasis did not read the CoreProtect config. No import starts.”** You answered no to the question about CoreProtect’s config. Run `/oasis import coreprotect` again and click **\[yes, read it]**. **“Nothing to confirm.”** The confirmation ran out after two minutes, or there was no preview. Run `/oasis import coreprotect` again. **“An import is already running.”** Only one import runs at a time. Check on it with `/oasis import status`. **“Import failed: … Fix the cause, then run /oasis import coreprotect again to carry on.”** Something went wrong partway, such as a lost connection. The import keeps its place, so fix the cause, then run the preview and confirm again. **Lots of rows counted as unknown** Usually these are blocks or items that Minecraft renamed since CoreProtect logged them, or mobs with old names. The summary tells you which table they’re in. Oasis can’t map them, because the current server doesn’t know those names.