Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-24678

mariabackup --prepare overwrites the backup content



    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.5.6
    • Fix Version/s: 10.5
    • Component/s: Backup
    • Labels:


      Restoring MariaDB backups taken with mariabackup utility requires to perform recovery on the backup files using the --prepare option. Using the --prepare option will make the backups consistent on the backup target, in other words "recover the database data" on the backup target.
      This requires that the backups can be overwritten, and that the backup devices supports seek calls, as only portion of the backup files will be overwritten (read and apply changes from the transaction logs to the database files?)

      A backup is intended to be a copy of the database taken at that time, and should be write protected hindering it from being corrupted by malwares, ransomware, bugs etc.

      From wikipedia regarding what a backup is:
      The general purpose of a backup is to prevent it from being destroyed, deleted, or corrupted, by placing the backups elsewhere, and protect it from being overwritten.
      The general purpose of a backup:

      • backup is a copy of computer data taken and stored elsewhere so that it may be used to restore the original after a data loss event.
      • Backups can be used to recover data after its loss from data deletion or corruption, or to recover data from an earlier time

      Other databases has two phases during a database restore.
      Phase 1: restore database data
      Phase 2: recover the database data
      The other databases recovery phase is performed after restoration of the database files, and on the targeted location.

      In MariaDB the phase looks like this:
      Phase 1: recover the database on the backup location
      Phase 2: restore the recovered database to the target location

      Suggesting MariaDB to change the order for the --prepare, so that these steps are done on the targeted device rather than on the backup location

      The utility also core dumps if the backup device is write protected.

      Output from the --prepare test:

      mysql@mariadb:~/::mariadb-backup --prepare --target-dir=/ptxfs_back/mysql/pf_test4
      mariadb-backup based on MariaDB server 10.5.6-4-MariaDB Linux (x86_64)
      [00] 2021-01-20 08:58:12 cd to /ptxfs_back/mysql/pf_test4/
      [00] 2021-01-20 08:58:13 This target seems to be not prepared yet.
      [00] 2021-01-20 08:58:13 mariabackup: using the following InnoDB configuration for recovery:
      [00] 2021-01-20 08:58:13 innodb_data_home_dir = .
      [00] 2021-01-20 08:58:13 innodb_data_file_path = ibdata1:12M:autoextend
      [00] 2021-01-20 08:58:13 innodb_log_group_home_dir = .
      [00] 2021-01-20 08:58:13 InnoDB: Using Linux native AIO
      [00] 2021-01-20 08:58:13 Starting InnoDB instance for recovery.
      [00] 2021-01-20 08:58:13 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
      2021-01-20 8:58:13 0 [Note] InnoDB: Uses event mutexes
      2021-01-20 8:58:13 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
      2021-01-20 8:58:13 0 [Note] InnoDB: Number of pools: 1
      2021-01-20 8:58:13 0 [Note] InnoDB: Using SSE4.2 crc32 instructions
      mariadb-backup: O_TMPFILE is not supported on /tmp (disabling future attempts)
      2021-01-20 8:58:13 0 [Note] InnoDB: Initializing buffer pool, total size = 104857600, chunk size = 104857600
      2021-01-20 8:58:13 0 [Note] InnoDB: Completed initialization of buffer pool
      2021-01-20 8:58:13 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
      2021-01-20 8:58:14 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=9504191888
      2021-01-20 8:58:15 0 [Warning] InnoDB: Retry attempts for writing partial data failed.
      2021-01-20 8:58:15 0 [ERROR] InnoDB: Write to file ./ib_logfile0 failed at offset 1536, 512 bytes should have been written, only 0 were written. Operating system error number 1. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
      2021-01-20 8:58:15 0 [ERROR] InnoDB: Error number 1 means 'Operation not permitted'

      2021-01-20 8:58:15 0 [Note] InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/
      2021-01-20 8:58:15 0 [ERROR] [FATAL] InnoDB: write(./ib_logfile0) returned I/O error
      210120 8:58:15 [ERROR] mysqld got signal 6 ;
      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.

      Server version: 10.5.6-4-MariaDB-enterprise
      It is possible that mysqld could use up to
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5990 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
      addr2line: 'mariadb-backup': No such file
      addr2line: 'mariadb-backup': No such file

      Printing to addr2line failed
      addr2line: 'mariadb-backup': No such file
      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 /ptxfs_back/mysql/pf_test4
      Resource Limits:
      Limit Soft Limit Hard Limit Units
      Max cpu time unlimited unlimited seconds
      Max file size unlimited unlimited bytes
      Max data size unlimited unlimited bytes
      Max stack size 8388608 unlimited bytes
      Max core file size unlimited unlimited bytes
      Max resident set unlimited unlimited bytes
      Max processes 31123 31123 processes
      Max open files 1024 4096 files
      Max locked memory 16777216 16777216 bytes
      Max address space unlimited unlimited bytes
      Max file locks unlimited unlimited locks
      Max pending signals 31123 31123 signals
      Max msgqueue size 819200 819200 bytes
      Max nice priority 0 0
      Max realtime priority 0 0
      Max realtime timeout unlimited unlimited us
      Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e

      Aborted (core dumped)




            serg Sergei Golubchik
            spictera Tomas
            5 Vote for this issue
            6 Start watching this issue



                Git Integration