LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   btrfs issue with mariadb incremental backup (https://www.linuxquestions.org/questions/linux-software-2/btrfs-issue-with-mariadb-incremental-backup-4175611539/)

siranee.ja 08-08-2017 02:06 AM

btrfs issue with mariadb incremental backup
 
I have problem with btrfs incremental send and receive from local to remote container.

My host Lxd is Ubuntu 16.04.3 LTS with lxd 2.0.10 and btrfs-progs v4.4

My 2 containers are centos7 (CentOS Linux release 7.3.1611 (Core) with

btrfs-progs-devel-4.4.1-1.el7.x86_64

btrfs-progs-4.4.1-1.el7.x86_64

mariadb-libs-5.5.52-1.el7.x86_64

mariadb-5.5.52-1.el7.x86_64

mariadb-server-5.5.52-1.el7.x86_64

The First mariadb centos7 container. (local btrfs)

I make btrfs sub volume /var/lib/mariadb/mysql for keeping mariadb database and make snapshot every day

The result btrfs snapshot example on The First mariadb centos7 container

ID 281 gen 195 top level 5 path mysql_201707210830
ID 288 gen 186 top level 5 path mysql_201707220830
ID 290 gen 191 top level 5 path mysql_201707230830
ID 292 gen 217 top level 5 path mysql

The Second mariadb centos7 container. (remote btrfs)

I make btrfs sub volume /var/lib/mariadb

1.1 send btrfs sub volume snapshot from The First mariadb centos7 container start with mysql_201707210830
1.2 send btrfs sub volume increamental between mysql_201707210830 and mysql_201707220830
1.3 send btrfs sub volume increamental between mysql_201707220830 and mysql_201707230830

The result btrfs snapshot example on The Second mariadb centos7 container

ID 270 gen 68 top level 5 path mysql_201707210830
ID 274 gen 66 top level 5 path mysql_201707220830
ID 276 gen 71 top level 5 path mysql_201707230830

I start to test the result on Second mariadb centos7 container with following procedure (first of all "cd /var/lib/mariadb ").

2.1 use command "btrfs sub snap mysql_201707210830 mysql" then "systemctl start mariadb" the result is fine mariadb works as expected. ( after this "systemctl stop mariadb" ,"btrfs sub del mysql" and "btrfs sub sync .")

2.2 use command "btrfs sub snap mysql_201707220830 mysql" then "systemctl start mariadb" the result is fine mariadb works as expected. ( after this "systemctl stop mariadb" ,"btrfs sub del mysql" and "btrfs sub sync .")

2.3 use command "btrfs sub snap mysql_201707230830 mysql" then "systemctl start mariadb" the result is not as expected!!!! mariadb cannot start.

Anyone please help me what steps that I make the mistake?

Best Regards,

Siranee Jaraswachirakul.

AwesomeMachine 08-08-2017 07:48 AM

I read through your post several times. The problem does not seem to be found in what you have presented.

siranee.ja 08-08-2017 08:40 PM

The problem is 2.3 "mariadb cannot start" with the following error

[root@joytest ~]# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.

[root@joytest ~]# systemctl status mariadb
● mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-08-09 08:36:21 ICT; 1min 46s ago
Process: 1001 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
Process: 1000 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
Process: 973 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Main PID: 1000 (code=exited, status=0/SUCCESS)

Aug 09 08:36:20 joytest systemd[1]: Starting MariaDB database server...
Aug 09 08:36:20 joytest mysqld_safe[1000]: 170809 08:36:20 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Aug 09 08:36:20 joytest mysqld_safe[1000]: 170809 08:36:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mariadb/mysql
Aug 09 08:36:21 joytest systemd[1]: mariadb.service: control process exited, code=exited status=1
Aug 09 08:36:21 joytest systemd[1]: Failed to start MariaDB database server.
Aug 09 08:36:21 joytest systemd[1]: Unit mariadb.service entered failed state.
Aug 09 08:36:21 joytest systemd[1]: mariadb.service failed.

[root@joytest ~]# cat /var/log/mariadb/mariadb.log

170809 08:39:42 mysqld_safe Starting mysqld daemon with databases from /var/lib/mariadb/mysql
170809 8:39:42 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
170809 8:39:42 [Note] /usr/libexec/mysqld (mysqld 5.5.52-MariaDB) starting as process 2154 ...
170809 8:39:42 InnoDB: The InnoDB memory heap is disabled
170809 8:39:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170809 8:39:42 InnoDB: Compressed tables use zlib 1.2.7
170809 8:39:42 InnoDB: Using Linux native AIO
170809 8:39:42 InnoDB: Initializing buffer pool, size = 512.0M
170809 8:39:42 InnoDB: Completed initialization of buffer pool
170809 8:39:42 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
170809 8:39:42 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Error: trying to access page number 4478943 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
170809 8:39:42 InnoDB: Assertion failure in thread 140511519488064 in file fil0fil.c line 5477
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/...-recovery.html
InnoDB: about forcing recovery.
170809 8:39:42 [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 http://kb.askmonty.org/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: 5.5.52-MariaDB
key_buffer_size=536870912
read_buffer_size=10485760
max_used_connections=0
max_threads=302
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 9807098 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
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 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5609942492dd]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x560993e5e8d5]
/lib64/libpthread.so.0(+0xf370)[0x7fcb62f30370]
/lib64/libc.so.6(gsignal+0x37)[0x7fcb616df1d7]
/lib64/libc.so.6(abort+0x148)[0x7fcb616e08c8]
/usr/libexec/mysqld(+0x6d562d)[0x56099409362d]
/usr/libexec/mysqld(+0x6a1ff3)[0x56099405fff3]
/usr/libexec/mysqld(+0x68b187)[0x560994049187]
/usr/libexec/mysqld(+0x65cd2b)[0x56099401ad2b]
/usr/libexec/mysqld(+0x64f643)[0x56099400d643]
/usr/libexec/mysqld(+0x6504ac)[0x56099400e4ac]
/usr/libexec/mysqld(+0x652c0e)[0x560994010c0e]
/usr/libexec/mysqld(+0x63bf65)[0x560993ff9f65]
/usr/libexec/mysqld(+0x5f7944)[0x560993fb5944]
/usr/libexec/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x560993e60958]
/usr/libexec/mysqld(+0x37cbc5)[0x560993d3abc5]
/usr/libexec/mysqld(_Z11plugin_initPiPPci+0x551)[0x560993d40531]
/usr/libexec/mysqld(+0x2eea6a)[0x560993caca6a]
/usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x546)[0x560993cafb86]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcb616cbb35]
/usr/libexec/mysqld(+0x2e8c0d)[0x560993ca6c0d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
170809 08:39:42 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended

siranee.ja 08-08-2017 09:11 PM

Hi AwesomeMachine,

Thank you for your kindly answer.

I wonder why mariadb can not start with the second incremental send and receive. As I show all steps of btrfs incremental send and receive. The first snapshot is the base snapshot and the first incremental make the mariadb start properly. Since second incremental and after that (third,forth... incremental) make the mariadb can not start with the mariadb log above.

I would like to ask for other opinions that who have the issue like me or I made something wrong in which steps or I have to upgrade the btrfs-progs to which version to solve the problem?


Best Regards,

Siranee Jaraswachirakul.

syg00 08-08-2017 09:47 PM

I am not in any way a db person, but I'd suspect this is more likely a db problem than btrfs. Do you lock the tables before every snap ?.

siranee.ja 08-08-2017 10:10 PM

Hi syg00,

yes I use the following backup script.

[root@backuplogC7 backup]# more backupsnap.sh
#Backup
#
user=$1
password=$2
basepath=$3
datet=$(date +%Y%m%d%H%M)
snappath=${basepath}_${datet}
echo "Locking databases"
mysql -u$user -p$password << EOF
FLUSH TABLES WITH READ LOCK;
system btrfs sub snap -r $basepath $snappath
UNLOCK TABLES;
quit
EOF
echo "Databases unlocked"

Best Regards,

Siranee Jaraswachirakul.

siranee.ja 08-08-2017 10:21 PM

Hi All,

Additional result that I tested with local snapshot (at The First mariadb centos7 container. (local btrfs))

I start to test the result on First mariadb centos7 container (local btrfs) with following procedure (first of all "cd /var/lib/mariadb " and "systemctl stop mariadb").

3.1 use command "btrfs sub snap mysql_201707210830 mysql" then "systemctl start mariadb" the result is fine mariadb works as expected. ( after this "systemctl stop mariadb" ,"btrfs sub del mysql" and "btrfs sub sync .")

3.2 use command "btrfs sub snap mysql_201707220830 mysql" then "systemctl start mariadb" the result is fine mariadb works as expected. ( after this "systemctl stop mariadb" ,"btrfs sub del mysql" and "btrfs sub sync .")

3.3 use command "btrfs sub snap mysql_201707230830 mysql" then "systemctl start mariadb" the result is fine mariadb works as expected.

This result show that local btrfs every snapshot work properly so I suspect with the mechanism when send and receive but I don't know how to prove this because the result from command btrfs send and receive not return any error.

Best Regards,


Siranee Jaraswachirakul.

syg00 08-08-2017 11:07 PM

That's a worry, we all need confidence send-receive works as expected. Raise a bug against btrfs and see what the devs have to say.

siranee.ja 08-08-2017 11:35 PM

Hi syg00,

Thank you for your kindly answer.
I sent email to linux-btrfs@vger.kernel.org with the reference url this thread and wait for hearing from them.

Best Regards,


Siranee Jaraswachirakul.

siranee.ja 08-14-2017 09:03 PM

Hi All,

With all help from the btrfs support team. Thanks you very much for the suggestions from "Chris Murphy" and "A L".

Finally I found the mistake steps which made the result incorrect. The tool to prove identical between source and destination snapshot send/receive is "rsync
-avnc /var/lib/mariadb/mysql_yyyymmddhhmm/ user@ip_destination:/var/lib/mariadb/mysql_yyyymmddhhmm/"


On Sat, Aug 12, 2017 at 8:20 PM, <siranee.ja@tpc.co.th> wrote:

> [root@backuplogC7 ~]# rsync -avnc /var/lib/mariadb/mysql_201708090830
> root@192.168.45.166://var/lib/mariadb/mysql_201708090830


You need trailing / for the first directory with -a option.

rsync -a dir dir

is not the same command as

rsync -a dir/ dir

It's confusing but your command is trying to create mysql_201708090830
directory on the source, in the mysql_201708090830 on the destination.
That is why everything mismatches. To make it mean "contents of" you
need trailing slash on at least the origin.



--
Chris Murphy


I didn't remember which steps that I made a mistake and made the mysql had Received UUID.

The main point that made the btrfs send/receive incremental incorrect is the current sub volume "mysql" had "Received UUID" which should occur when receive at destination site (Remote) but in my case it appeared at source site (Local).

> On 8/13/2017 12:52 PM, siranee.ja@tpc.co.th wrote:
>> Hi "A L",
>>
>> [root@backuplogC7 ~]# btrfs sub show /var/lib/mariadb/mysql
>> /var/lib/mariadb/mysql
>> Name: mysql
>> UUID: 92f319c5-e132-3249-9b13-d39ee77a2b44
>> Parent UUID: -
>> Received UUID: 3ad0334a-4063-654c-add6-b1cbcdeaa639
>> Creation time: 2017-06-21 13:27:41 +0700
>> Subvolume ID: 257
>> Generation: 539
>> Gen at creation: 9
>> Parent ID: 5
>> Top level ID: 5
>> Flags: -
>> Snapshot(s):
>> mysql_201708060830
>> mysql_201708070830
>> mysql_201708080830
>> mysql_201708090830
>> mysql_201708100830
>> mysql_201708110830
>> mysql_201708120830
>> mysql_201708130830
>>
>> yes I think it has Received UUID because I restored the source from snapshot
>> mysql_201708040830 for prove that the local snapshot was work.
>>
>> How to clear the Received UUID ?
>> What to do next?
> You need to make a read-write snapshot of /var/lib/mariadb/mysql and
> then remove the old subvolume and all its snapshots.
>
> Example from https://github.com/digint/btrbk/blob/master/doc/FAQ.md
>
> # cd /mnt/btr_pool
> # mv mysubvolume mysubvolume.broken
> # btrfs subvolume snapshot mysubvolume.broken mysubvolume
>
> You can do the same with each of your snapshots too, and send them as
> full snapshots (without -p).
>
> ~A

-- as recommend from https://github.com/digint/btrbk/blob/master/doc/FAQ.md --


"I'm getting an error: Aborted: "Received UUID" is set

You probably restored a backup with send-receive, and made it read/write using btrfs
property set. This is bad, as all snapshots and backups will inherit this identical
"Received UUID", which results in all these subvolumes will be treated as
"containing same data".

To fix this, create a "proper" snapshot:

- This is as your suggestion for the subvolume "mysql"

# cd /mnt/btr_pool
# mv mysubvolume mysubvolume.broken
# btrfs subvolume snapshot mysubvolume.broken mysubvolume

Now, mysubvolume should have an empty "Received UUID". Note that in order to have a
clean environment, you also need to fix all subvolumes (snapshots as well as
backups) that you created with the broken subvolume.

Check if there are more broken subvolumes:

# btrfs subvolume show mysubvolume.broken
# btrfs subvolume list -a -R /mnt/btr_pool | grep <"Received UUID" from above>
# btrfs subvolume list -a -R /mnt/btr_backup | grep <"Received UUID" from above>

- This guide seem that I have to clear <"Received UUID" > only the subvolume "mysql"
and the others ("mysql_201708070830" should using btrfs subvolume snapshot -r
instead of btrfs subvolume snapshot. Is this correct?

Now clean all subvolume listed (same as above, but using btrfs subvolume snapshot -r
now). Then delete all the broken subvolumes:

# btrfs subvolume delete *.broken

Finally, you should have a clean environment, and btrbk will not complain any more.


Last procedure to repair the broken snapshot subvolumes are following.

I have done the following and it work as it should be right now.

[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708070830
rw_201708070830
Create a snapshot of 'mbroken_201708070830' in './rw_201708070830'
[root@backuplogC7 mariadb]# btrfs sub list .
ID 257 gen 542 top level 5 path mbroken
ID 317 gen 576 top level 5 path mbroken_201708070830
ID 318 gen 568 top level 5 path mbroken_201708080830
ID 319 gen 569 top level 5 path mbroken_201708090830
ID 320 gen 570 top level 5 path mbroken_201708100830
ID 321 gen 571 top level 5 path mbroken_201708110830
ID 322 gen 572 top level 5 path mbroken_201708120830
ID 323 gen 573 top level 5 path mbroken_201708130830
ID 324 gen 543 top level 5 path mysql
ID 348 gen 576 top level 5 path rw_201708070830
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708080830
rw_201708080830
Create a snapshot of 'mbroken_201708080830' in './rw_201708080830'
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708090830
rw_201708090830
Create a snapshot of 'mbroken_201708090830' in './rw_201708090830'
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708100830
rw_201708100830
Create a snapshot of 'mbroken_201708100830' in './rw_201708100830'
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708110830
rw_201708110830
Create a snapshot of 'mbroken_201708110830' in './rw_201708110830'
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708120830
rw_201708120830
Create a snapshot of 'mbroken_201708120830' in './rw_201708120830'
[root@backuplogC7 mariadb]# btrfs subvolume snapshot mbroken_201708130830
rw_201708130830
Create a snapshot of 'mbroken_201708130830' in './rw_201708130830'
[root@backuplogC7 mariadb]# btrfs sub list .
ID 257 gen 542 top level 5 path mbroken
ID 317 gen 576 top level 5 path mbroken_201708070830
ID 318 gen 577 top level 5 path mbroken_201708080830
ID 319 gen 578 top level 5 path mbroken_201708090830
ID 320 gen 579 top level 5 path mbroken_201708100830
ID 321 gen 580 top level 5 path mbroken_201708110830
ID 322 gen 581 top level 5 path mbroken_201708120830
ID 323 gen 582 top level 5 path mbroken_201708130830
ID 324 gen 543 top level 5 path mysql
ID 348 gen 576 top level 5 path rw_201708070830
ID 349 gen 577 top level 5 path rw_201708080830
ID 350 gen 578 top level 5 path rw_201708090830
ID 351 gen 579 top level 5 path rw_201708100830
ID 352 gen 580 top level 5 path rw_201708110830
ID 353 gen 581 top level 5 path rw_201708120830
ID 354 gen 582 top level 5 path rw_201708130830
[root@backuplogC7 mariadb]# btrfs subvolume list -a -R . | grep
"3ad0334a-4063-654c-add6-b1cbcdeaa639"
ID 257 gen 542 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken
ID 317 gen 576 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708070830
ID 318 gen 577 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708080830
ID 319 gen 578 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708090830
ID 320 gen 579 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708100830
ID 321 gen 580 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708110830
ID 322 gen 581 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708120830
ID 323 gen 582 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708130830
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708070830 mysql_201708070830
Create a readonly snapshot of 'rw_201708070830' in './mysql_201708070830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708080830 mysql_201708080830
Create a readonly snapshot of 'rw_201708080830' in './mysql_201708080830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708090830 mysql_201708090830
Create a readonly snapshot of 'rw_201708090830' in './mysql_201708090830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708100830 mysql_201708100830
Create a readonly snapshot of 'rw_201708100830' in './mysql_201708100830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708110830 mysql_201708110830
Create a readonly snapshot of 'rw_201708110830' in './mysql_201708110830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708120830 mysql_201708120830
Create a readonly snapshot of 'rw_201708120830' in './mysql_201708120830'
[root@backuplogC7 mariadb]# btrfs sub snap -r rw_201708130830 mysql_201708130830
Create a readonly snapshot of 'rw_201708130830' in './mysql_201708130830'
[root@backuplogC7 mariadb]# btrfs sub list .
ID 257 gen 542 top level 5 path mbroken
ID 317 gen 576 top level 5 path mbroken_201708070830
ID 318 gen 577 top level 5 path mbroken_201708080830
ID 319 gen 578 top level 5 path mbroken_201708090830
ID 320 gen 579 top level 5 path mbroken_201708100830
ID 321 gen 580 top level 5 path mbroken_201708110830
ID 322 gen 581 top level 5 path mbroken_201708120830
ID 323 gen 582 top level 5 path mbroken_201708130830
ID 324 gen 584 top level 5 path mysql
ID 348 gen 583 top level 5 path rw_201708070830
ID 349 gen 584 top level 5 path rw_201708080830
ID 350 gen 585 top level 5 path rw_201708090830
ID 351 gen 586 top level 5 path rw_201708100830
ID 352 gen 587 top level 5 path rw_201708110830
ID 353 gen 588 top level 5 path rw_201708120830
ID 354 gen 589 top level 5 path rw_201708130830
ID 355 gen 583 top level 5 path mysql_201708070830
ID 356 gen 584 top level 5 path mysql_201708080830
ID 357 gen 585 top level 5 path mysql_201708090830
ID 358 gen 586 top level 5 path mysql_201708100830
ID 359 gen 587 top level 5 path mysql_201708110830
ID 360 gen 588 top level 5 path mysql_201708120830
ID 361 gen 589 top level 5 path mysql_201708130830

[root@backuplogC7 mariadb]# btrfs subvolume list -a -R . | grep
"3ad0334a-4063-654c-add6-b1cbcdeaa639"
ID 257 gen 542 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken
ID 317 gen 576 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708070830
ID 318 gen 577 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708080830
ID 319 gen 578 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708090830
ID 320 gen 579 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708100830
ID 321 gen 580 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708110830
ID 322 gen 581 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708120830
ID 323 gen 582 top level 5 received_uuid 3ad0334a-4063-654c-add6-b1cbcdeaa639 path
mbroken_201708130830
[root@backuplogC7 mariadb]# btrfs send /var/lib/mariadb/mysql_201708070830 | ssh
192.168.45.166 btrfs receive /var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708070830
At subvol mysql_201708070830
[root@backuplogC7 mariadb]# btrfs sub show mysql_201708070830
/var/lib/mariadb/mysql_201708070830
Name: mysql_201708070830
UUID: 70ee3c31-126d-574a-814c-e3b4c81b414e
Parent UUID: 1d5bb8eb-b0df-2549-8b62-552cfa517609
Received UUID: -
Creation time: 2017-08-14 07:00:08 +0700
Subvolume ID: 355
Generation: 583
Gen at creation: 583
Parent ID: 5
Top level ID: 5
Flags: readonly
Snapshot(s):
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708070830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708070830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 1083.43 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708070830
/var/lib/mariadb/mysql_201708080830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708080830
At snapshot mysql_201708080830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708080830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708080830/
sending incremental file list
./

sent 3769 bytes received 19 bytes 688.73 bytes/sec
total size is 718361496 speedup is 189641.37 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708080830
/var/lib/mariadb/mysql_201708090830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708090830
At snapshot mysql_201708090830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708090830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708090830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 583.38 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708090830
/var/lib/mariadb/mysql_201708100830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708100830
At snapshot mysql_201708100830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708100830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708100830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 689.45 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708100830
/var/lib/mariadb/mysql_201708110830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708110830
At snapshot mysql_201708110830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708110830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708110830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 689.45 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708110830
/var/lib/mariadb/mysql_201708120830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708120830
At snapshot mysql_201708120830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708120830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708120830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 689.45 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]# btrfs send -p /var/lib/mariadb/mysql_201708120830
/var/lib/mariadb/mysql_201708130830 | ssh 192.168.45.166 btrfs receive
/var/lib/mariadb
At subvol /var/lib/mariadb/mysql_201708130830
At snapshot mysql_201708130830
[root@backuplogC7 mariadb]# rsync -avnc /var/lib/mariadb/mysql_201708130830/
root@192.168.45.166:/var/lib/mariadb/mysql_201708130830/
sending incremental file list
./

sent 3773 bytes received 19 bytes 689.45 bytes/sec
total size is 718361496 speedup is 189441.32 (DRY RUN)
[root@backuplogC7 mariadb]#

syg00 08-14-2017 09:46 PM

Thanks for the update post. Glad it got sorted, and the reason(s) is clear.


All times are GMT -5. The time now is 08:08 PM.