Database Issues after cloning the entire drive

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 21.0.8.3
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04.6 LTS
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.41
PHP version (eg, 7.4): PHP 7.4.3

The issue you are facing:

I moved the nextcloud server from one RAID Array to another using DD while Nextcloud was in Maintenance mode. I unfortunately only tested if the server was running and accessible, not if my Nextcloud instance was running properly.
After some days I tried accessing my Nextcloud instance and got this error message in the web interface:

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

Running the OCC command returns the following output:

An unhandled exception has been thrown:
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] No such file or directory in /var/www/nextcloud/lib/private/DB/Connection.php:139
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1519): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1041): Doctrine\DBAL\Connection->getWrappedConnection()
#2 /var/www/nextcloud/lib/private/DB/Connection.php(261): Doctrine\DBAL\Connection->executeQuery()
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(345): OC\DB\Connection->executeQuery()
#4 /var/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(281): Doctrine\DBAL\Query\QueryBuilder->execute()
#5 /var/www/nextcloud/lib/private/AppConfig.php(419): OC\DB\QueryBuilder\QueryBuilder->execute()
#6 /var/www/nextcloud/lib/private/AppConfig.php(184): OC\AppConfig->loadConfigValues()
#7 /var/www/nextcloud/lib/private/AppConfig.php(375): OC\AppConfig->getApps()
#8 /var/www/nextcloud/lib/private/legacy/OC_App.php(967): OC\AppConfig->getValues()
#9 /var/www/nextcloud/lib/private/Server.php(725): OC_App::getAppVersions()
#10 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(162): OC\Server->OC\{closure}()
#11 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#12 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(129): Pimple\Container->offsetGet()
#13 /var/www/nextcloud/lib/private/ServerContainer.php(136): OC\AppFramework\Utility\SimpleContainer->query()
#14 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(57): OC\ServerContainer->query()
#15 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(184): OC\AppFramework\Utility\SimpleContainer->get()
#16 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(162): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#17 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#18 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(129): Pimple\Container->offsetGet()
#19 /var/www/nextcloud/lib/private/ServerContainer.php(136): OC\AppFramework\Utility\SimpleContainer->query()
#20 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(57): OC\ServerContainer->query()
#21 /var/www/nextcloud/lib/private/Server.php(1121): OC\AppFramework\Utility\SimpleContainer->get()
#22 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(162): OC\Server->OC\{closure}()
#23 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#24 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(129): Pimple\Container->offsetGet()
#25 /var/www/nextcloud/lib/private/ServerContainer.php(136): OC\AppFramework\Utility\SimpleContainer->query()
#26 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(57): OC\ServerContainer->query()
#27 /var/www/nextcloud/lib/private/Server.php(2072): OC\AppFramework\Utility\SimpleContainer->get()
#28 /var/www/nextcloud/lib/private/Files/View.php(117): OC\Server->getLockingProvider()
#29 /var/www/nextcloud/lib/private/Server.php(462): OC\Files\View->__construct()
#30 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(162): OC\Server->OC\{closure}()
#31 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(122): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#32 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(129): Pimple\Container->offsetGet()
#33 /var/www/nextcloud/lib/private/ServerContainer.php(136): OC\AppFramework\Utility\SimpleContainer->query()
#34 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(57): OC\ServerContainer->query()
#35 /var/www/nextcloud/lib/private/Server.php(1474): OC\AppFramework\Utility\SimpleContainer->get()
#36 /var/www/nextcloud/lib/base.php(617): OC\Server->boot()
#37 /var/www/nextcloud/lib/base.php(1145): OC::init()
#38 /var/www/nextcloud/console.php(48): require_once('/var/www/nextcl...')
#39 /var/www/nextcloud/occ(11): require_once('/var/www/nextcl...')
#40 {main}

Steps to replicate it:

  1. Send your nextcloud instance into maintenance mode using the OCC command
  2. Clone your system using DD
  3. Reboot your system and attempt to access it via the web interface

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'occhplgssw64',
  'passwordsalt' => 'PASSWORD',
  'secret' => 'L4Y8yrPOXPAkzSoMkcq79tki33iBxS59Nk6+blrdgtMiP1ot',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '192.168.178.49',
    2 => 'DOMAIN_NAME',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '25.0.6.1',
  'overwrite.cli.url' => 'http://localhost/nextcloud',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'USER',
  'dbpassword' => 'DATABASE_PASSWORD',
  'installed' => true,
  'mail_from_address' => 'MAIL_ADRESS',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'MAIL_DOMAIN',
  'maintenance' => false,
  'updater.secret' => 'SECRET',
  'loglevel' => 2,
  'theme' => '',
  'data-fingerprint' => 'SECRET',
);

Nextcloud.log contained no information connected to this issue, all error messages are older than the earliest instance of this issue.

I need help getting my instance running again, I have an up to date backup on an hard drive that was made using the same procedure so I assume it to have the same issue.
Thanks for your patience :smiley:

When you say you moved your Nextcloud “server” I assume you mean the entire stack: web + db (perhaps not redis as it doesn’t look like you’re using it).

I assume there was some sort of typo when your provided info because you provided two different NC versions. :slight_smile:

It sounds like your db server is offline (or, at the very minimum, the path to the UNIX socket used to connect to it has changed - since when you’re dbhost is set to localhost I believe DBAL will try to use a UNIX socket rather than TCP).

Ignore your web service (and NC itself) for a moment, and check on the state of your mysql service. Depending on how it’s set up you may even find some mysql logs either under /var/log or in the configured mysql data directory (typically something like /var/lib/mysql).

In addition to the mysql logs, you can test your mysql service by connecting to it from its own client app. The mysql command client client can be run with a command along the lines of mysql -uroot -p - or better yet: mysql -u <dbuser> -p<dbpassword> (both from your NC config.php).

Until the mysql service is running without errors, you won’t be able to get NC to run.

Hopefully move with dd while mysql was still running didn’t mess up the db too much for an auto-recovery to work. If NC was in maintenance mode things should have been fairly quiet so it’s often recoverable in my experience even if it’s not a great idea.

Hello and Thank you for your reply, I attempted running the command and got the following return:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

I hope that narrows down the problem a bit further :slight_smile:

What, specifically, do you mean by cloned your Nextcloud server? Just moved the contents of /var/www/nextcloud/data folder to this new array than remounted it back in the same place? Did you move anything else? Did any parts of the OS get moved too?

You need to figure out what the deal is with your MySQL server. If you installed it from a package it’ll show up under dpkg like so:

sudo dpkg -l | grep mysql

(Possibly mariadb rather than mysql check that too)

If it’s installed, check the status of the service:

sudo systemctl status mysql

I copied the entire file system of the root drive, assuming the maintenance mode would bring the database into a state that won’t hurt it while copying it with dd. The entire stack with the operating system was copied to this new array. Assuming the maintenance mode would save the database from damage.
To further clarify, I literally ran:
dd if=/dev/sda of=/dev/sdb

I ran the command once with mysql and once with MariaDB giving the following results:
sudo dpkg -l | grep mysql

ii  libdbd-mysql-perl:amd64                    4.050-3                             amd64        Perl5 database interface to the MariaDB/MySQL database
ii  libmysqlclient21:amd64                     8.0.33-0ubuntu0.20.04.2             amd64        MySQL database client library
ii  mysql-common                               5.8+1.0.5ubuntu2                    all          MySQL database common files, e.g. /etc/mysql/my.cnf
ii  php7.4-mysql                               7.4.3-4ubuntu2.18                   amd64        MySQL module for PHP

sudo dpkg -l | grep MariaDB

ii  mariadb-client-10.3                        1:10.3.38-0ubuntu0.20.04.1          amd64        MariaDB database client binaries
ii  mariadb-client-core-10.3                   1:10.3.38-0ubuntu0.20.04.1          amd64        MariaDB database core client binaries
ii  mariadb-common                             1:10.3.38-0ubuntu0.20.04.1          all          MariaDB common metapackage
ii  mariadb-server                             1:10.3.38-0ubuntu0.20.04.1          all          MariaDB database server (metapackage depending on the latest version)
ii  mariadb-server-10.3                        1:10.3.38-0ubuntu0.20.04.1          amd64        MariaDB database server binaries
ii  mariadb-server-core-10.3                   1:10.3.38-0ubuntu0.20.04.1          amd64        MariaDB database core server files

Since I’m not using MySQL I ran the following command:
sudo systemctl status mariadb
Which gave me this in return:

● mariadb.service - MariaDB 10.3.38 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: signal) since Sat 2023-05-20 20:51:08 CEST; 1s ago
       Docs: man:mysqld(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 780674 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 780675 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 780677 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-envir>
    Process: 780724 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=killed, signal=SEGV)
   Main PID: 780724 (code=killed, signal=SEGV)
     Status: "Starting final batch to recover 12 pages from redo log"

Is there realisticly anything I can do or is my server beyond rescue at this point?

It looks like MariaDB is trying to recover. How long has it been running?

There will be more information in the MariaDB logs.

Recovering a broken database is a challenging topic to take up in a forum post.

You have backups, right? Or access to the old array?

If you don’t have something like the output of mariadb-dump (aka: mysqldump same thing) you should be able to restore the contents of /var/lib/mysql from a recent backup just prior to the dd in place of what’s there (may want to move the existing messed up contents of /var/lib/mysql somewhere rather than just write over it so you don’t accidentally inherit anything that doesn’t get overwritten by the restore but is still messed up).

Something like:

sudo systemctl status mariadb ← where you’re at now
sudo systemctl stop mariadb ← stop the database service
sudo systemctl status mariadb ← confirm it’s stopped
mv /var/lib/mysql /var/lib/mysql.broken ← move the broken stuff out of the way
[...] ← do your restore to /var/lib/mysql and check the file ownership/permissions match /var/lib/mysql/broken)
sudo systemctl start mariadb ← start the db service
sudo systemctl status mariadb ← see if it worked

Whatever you do, make sure you stop the existing MariaDB service prior to attempting the restore!

Think about things like this: NC is just an application running on your system. It has no control over the database or other components of your operating system. Maintenance mode in NC is just for NC itself. To migrate an entire operating system and all the pieces running on top of it to another drive/system requires shutting all services down (or knowing which services are safe to keep online or having specific nuanced data migration approaches in mind that know how to handle things like an actively running database).

I’m sorry this happened to you and hopefully the above still leads to a reasonable recovery without having to restart from scratch!

Thank you for your replies, I’ve been looking at the contents of the MariaDB logs. It apears that it is attempting to do some kind of recovery every 10 minutes. It apears to abort without success. Here are the logs, I’ve only pasted a section since the content seem identical every 10 minutes:

Server version: 10.3.38-MariaDB-0ubuntu0.20.04.1 source revision: c73985f2ce8a391582787f3e310a011c1a712bec
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467435 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x32)[0x55b204de7be2]
/usr/sbin/mysqld(handle_fatal_signal+0x55d)[0x55b2048db1cd]
sigaction.c:0(__restore_rt)[0x7f23580da420]
/usr/sbin/mysqld(+0x4d1daf)[0x55b2045d9daf]
/usr/sbin/mysqld(+0x9e8adc)[0x55b204af0adc]
/usr/sbin/mysqld(+0x9e921f)[0x55b204af121f]
/usr/sbin/mysqld(+0x9cf6cd)[0x55b204ad76cd]
/usr/sbin/mysqld(+0x9d0530)[0x55b204ad8530]
/usr/sbin/mysqld(+0x4cde05)[0x55b2045d5e05]
/usr/sbin/mysqld(+0x4f2dcc)[0x55b2045fadcc]
/usr/sbin/mysqld(+0xb1f456)[0x55b204c27456]
/usr/sbin/mysqld(+0xa5c8d8)[0x55b204b648d8]
nptl/pthread_create.c:478(start_thread)[0x7f23580ce609]
addr2line: DWARF error: section .debug_info is larger than its filesize! (0x93ef57 vs 0x530ea0)
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f2357ff3133]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
2023-05-27  0:16:44 0 [Note] Starting MariaDB 10.3.38-MariaDB-0ubuntu0.20.04.1 source revision c73985f2ce8a391582787f3e310a011c1a712bec as process 3590539
2023-05-27  0:16:44 0 [Note] InnoDB: Using Linux native AIO
2023-05-27  0:16:44 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-05-27  0:16:44 0 [Note] InnoDB: Uses event mutexes
2023-05-27  0:16:44 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-05-27  0:16:44 0 [Note] InnoDB: Number of pools: 1
2023-05-27  0:16:44 0 [Note] InnoDB: Using SSE2 crc32 instructions
2023-05-27  0:16:44 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2023-05-27  0:16:44 0 [Note] InnoDB: Completed initialization of buffer pool
2023-05-27  0:16:44 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2023-05-27  0:16:44 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=68490579606
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=794] log sequence number 68490889069 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=814] log sequence number 68490889592 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=795] log sequence number 68490890082 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=821] log sequence number 68490891254 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=792] log sequence number 68490891585 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=771] log sequence number 68490891927 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=793] log sequence number 68490901243 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=801] log sequence number 68490771563 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=781] log sequence number 68490771915 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=825] log sequence number 68490771959 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=784] log sequence number 68490772019 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=788] log sequence number 68490772063 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=776] log sequence number 68490772239 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=772] log sequence number 68490772283 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=787] log sequence number 68490772459 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=791] log sequence number 68490772651 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=789] log sequence number 68490772783 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=785] log sequence number 68490772827 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=773] log sequence number 68490773107 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=777] log sequence number 68490828874 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=778] log sequence number 68490829006 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=780] log sequence number 68490829390 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=779] log sequence number 68490829478 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=782] log sequence number 68490830098 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=790] log sequence number 68490830186 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=786] log sequence number 68490830570 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=783] log sequence number 68490830790 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=768] log sequence number 68490890538 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Page [page id: space=0, page number=770] log sequence number 68490890582 is in the future! Current system log sequence number 68490651097.
2023-05-27  0:16:44 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-05-27  0:16:44 0 [Note] InnoDB: Starting final batch to recover 12 pages from redo log.
230527  0:16:44 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

My most recent backups are stored on a hard drive that is currently not available to me. I’ve recovered the contents of

/nextcloud/data/

Via SCP to my main Machine.

Since I urgently need this machine to work I’ll attempt to implement this fix:

I prepared a USB Stick with a live Linux Distro to copy the system over if I can recover successfully. This should at least keep the database safe.

Do you reckon my Database or Calender info are salvageable? The error log is giving me very low confidence. :slight_smile:

@Pusheen do you recall how (and if) you resolved this? I seem to have a similar issue after trying to move to a new hard drive following these instructions.

If you did a database dump according to the guide, try to recover this one. Probably some filesystem corruption occurred while copying the raw data.

Thanks Michalng, There’s no mention of a database dump in the description for Solution 2; I’m guessing it was discussed earlier and applied to both solutions but I missed the connection. Either way, I didn’t do a database dump, so that may narrow things down a bit

Ah right, it was only included in solution 1 as this implies manipulating database entries. Then I do not think that you are facing the same issue as OP, who did actually move the database files along with the whole data.

Please open a new topic and ping me there. Add the logs of your database server:

journalctl -u mariadb

I created a new topic here: MariaDB down after creating symlink from old to new datadir.