Opened 6 weeks ago

Last modified 2 weeks ago

#818 assigned defect

Data not restored after performing Mondo restore from NFS

Reported by: xsagipp Owned by: bruno
Priority: highest Milestone: 3.0.5
Component: mondo Version: 3.0.4
Severity: blocker Keywords: Mondo Restore
Cc:

Description

Issue : After successful completion of restore(no issues/errors/warnings reported) by Mondo, the server rebooted. We found that the data that was removed after backup was not restored and the data created after the backup was still available.

Hence, although Mondo GUI claims that restore has been completed successfully, we cannot see the old backed up data after restoration by Mondo.

Steps Performed :

1) Backup using the below command :

/usr/sbin/mondoarchive -On nfs4://bgelx129:/nfsshare -k /boot/vmlinuz-3.0.101-100-default -d bgelx131 -N -I '/' -E '/opt/mondo_lkRtrL|/var/lib/ntp/proc|/dev/mapper/*|/dev/md/*|/dev/sdf*|/dev/sdc*|/dev/sde*|/dev/sdb*|/dev/sdg*|/dev/sdd*' -s 4380m -p bgelx131_BCK_20170705_154618 -S /opt/mondo-scratch -T /opt/mondo-tmp -f /dev/sda2

2) Boot up from the first ISO created(i.e bgelx131_BCK_20170705_154618-1.iso) to Mondo Restore top level window.

3) Selected "Exit to Shell", created temporary mount directory and mounted the NFS server's share location.

4) Executed mondorestore to open the top level window and selected "Automatically"

5) Selected "Net mount" and entered respective details like Network User, Network Share, etc.,

7) Restore completed and rebooted the server.

9) Logged on to the restored server and verified if the deleted files are restored, but observed that they are not restored.

Also, unable to find the /var/log/mondorestore.log although Mondo claims that it has restored the system successfully.

Attachments (2)

Logs.zip (99.3 KB) - added by xsagipp 6 weeks ago.
Attached zip file containing mindi.log and mondoarchive.log
mondorestore.zip (52.0 KB) - added by xsagipp 5 weeks ago.

Download all attachments as: .zip

Change History (7)

Changed 6 weeks ago by xsagipp

Attached zip file containing mindi.log and mondoarchive.log

comment:1 Changed 6 weeks ago by bruno

Before rebooting, capture the mondorestore.log file. Without it, there is no way I can help with this issue.

Your version is pretty old, and you should move to the 3.2 branch instead. THere won't be any evolution on the 3.0 one.

comment:2 Changed 6 weeks ago by xsagipp

Hi Bruno,

I tried to copy the log to a directory(here, I used /usr), but I cannot see the same after reboot.

Could you please suggest a way to capture it.

comment:3 Changed 6 weeks ago by bruno

You should mount a USB Key and copy your files to it if you want to get them back. Another possibility is to use a shared NFS drive.

Changed 5 weeks ago by xsagipp

comment:4 Changed 5 weeks ago by xsagipp

Attached the mondorestore log. Could you please check now.

comment:5 Changed 2 weeks ago by bruno

  • Status changed from new to assigned

It seems that mondorestore didn't format some FS:

running: sh -c 'echo -en "y\ny\ny\n" | mkswap /dev/sde1' > /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.tmp 2> /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
Setting up swapspace version 1, size = 146483320 KiB
no label, UUID=a670cb5a-7ad6-4c4d-983d-7bf53ee7a08e
mkswap: /dev/sde1: warning: don't erase bootbits sectors
(dos partition table detected). Use -f to force.
--------------------------------end of output------------------------------

This has been fixed in more recent versions of mondorestore as in 3.2.2 below:

../../tags/3.2.2/mondo/src/mondorestore/mondo-prep.c:   mr_asprintf(program, "mkswap -f");
../../tags/3.2.2//mondo/src/restore-scripts/mondo/mr-label-partitions-as-necessary:                                 command="mkswap -f $opttun $label $mountpt"

A workaround would be to erase with dd the partitions before usage.

Also I see:

running: sh -c 'echo -en "y\ny\ny\n" | mkfs -t ext3 -F -q /dev/sda2' > /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.tmp 2> /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
mkfs.ext3: No such file or directory while trying to determine filesystem size
--------------------------------end of output------------------------------

There was an error saying that parioning didn't happened correctly. For your tests, to be sure, the best approach is to erase disks before operation (dd) or change them if possible.

However as the FS was previously existing, it could be mounted as /dev/sda2 (as shown in the log) and retsoration occured on it (so it restored files, but kept new ones for example).

This is strange as that command was backed up by mindi in the boot environment (it's analyzed in your mindi.log) with it's deps:

/sbin/mkfs.ext3
/lib64/libext2fs.so.2
/lib64/libext2fs.so.2
/lib64/libext2fs.so.2.4
/lib64/libcom_err.so.2
/lib64/libcom_err.so.2
/lib64/libcom_err.so.2.1
/lib64/libblkid.so.1
/lib64/libblkid.so.1
/lib64/libblkid.so.1.1.0
/lib64/libuuid.so.1
/lib64/libuuid.so.1
/lib64/libuuid.so.1.3.0
/lib64/libe2p.so.2
/lib64/libe2p.so.2
/lib64/libe2p.so.2.3
/lib64/libc.so.6
/lib64/libc.so.6
/lib64/libc-2.11.3.so
/lib64/libpthread.so.0
/lib64/libpthread.so.0
/lib64/libpthread-2.11.3.so
/lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2
/lib64/ld-2.11.3.so

So I don't know why it's not accessible at restore time here.

Could you at restore time, once the boot has been performed and before restoring go to the shell and type mkfs -t ext3 -F /dev/sda2 and provide the messages reported please ?

Also give the result of ls -al /sbin/mkfs.ext3 (should be there)

Note: See TracTickets for help on using tickets.