{5} Assigned, Active Tickets by Owner (Full Description) (66 matches)

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.

Hello, i'm using sles 10 sp2 x62_64 with mondo 2.2.8-1.

The archive prozess running fine, but when i start restore on the same Hardware he stops every time at the same position. He can't configure the harddisks/raids. When i look of the partition with fdisk after mondo stops it looks not nice ( see fdisk.jpg ). I see on device /dev/cciss/c0d1p2 start and end cylinder at 1. The orignal system have no second partion on this device( see fdisk_original.jpg ).

Hi,

I have been have recently installed v3.0.4 on RHEL5u6. I have upgraded from v2.2.9.5 due to problems occuring when backing up large sparse files and it using v3.0.4.

I have a major problem with the restore.

1. At the end of the restore I have the message ' No tarballs. Strange. Maybe you only backed up freakin' big files?'.
2. exit does not work. It complains about the trap command.
3. When I try to reboot grub is corrupted. I get error 15.

The command I used to create the archive was /usr/sbin/mondoarchive -OVi -R -N -d /opt -S /opt/backups -T /opt/backups -E "/opt|/opt/backups" -s 16384mb -G -p mondo3.0.4-bkup

Can anybody help me please. I have included the logs and error

This ticket is raised at the request of Bruno as a result of a mailing list discussion. See archive: Date=June 10 2012 Title=3.0.2-1 Fail to Restore from External Hard Disk

A single mondorescue-1.iso backup is successfully created directly to an external hard disk and stored in /mondo.

Booting from the mondorescue.iso (mindi) CDROM

• Boot codes: interactive noresize
• Read from=Hard disk
• Prefix=mondorescue
• On what device do the ISO files live=/dev/sdb1
• What is disk format=ext4
• Are you restoring from an external hard drive=Yes
• At what path on this device can the ISO files be found=/mondo
• When mondorestore displays the message "Failed to find config/file archives. Choose another source?"
• ALT-F2
• mount "... /dev/sdb1 on /tmp/isodir type ext4 (ro,relatime,barrier=1,data=ordered)"
• ls -1 /mnt/isodir/mondo/*.iso "/tmp/isodir/mondo/mondorescue-1.iso /tmp/isodir/mondo/mondorescue.iso"

It seems that mondorestore mounts the external disk OK but does not use the path to the directory holding the backup ISO.

At the suggestion of Bruno mondorescue-1.iso was copied to the root of the external drive and the restore attempted again. This time the ISO is found but the restore fails at a later stage.

Booting from the mondorescue.iso (mindi) CDROM

• Boot codes: interactive noresize
• Read from=Hard disk
• Prefix=mondorescue
• On what device do the ISO files live=/dev/sdb1
• What is disk format=ext4
• Are you restoring from an external hard drive=Yes
• At what path on this device can the ISO files be found=/
• Editing Mountlist=OK
• Save mountlist and continue=Yes
• Erase and partition hard drives=Yes
• Restore all data=Yes
• A message is displayed "Please insert ISO #1 and press Enter"

At this point the mondorestore.log was saved as it is not possible to proceed further. The log is attached.

When restoring to a hardware setup different than the original (i.e. different RAID/SATA adapter) you can be caught in a catch22 situation wherer you can NOT load the needed kernel modules because mondo/mindi did NOT put ALL OF THEM on the bootable portion of the image. the only current solution is to KNOW the drivers needed BEFORE the mondoarchive (backup) is even done so that they can be "modprobed" into memory so that mondo/mindi makes surethey are available.

A more appropriate and correct solution would be to have the ENTIRE kernel modules tree be accessible after booting in rescue mode (i.e. on new hardware). in case hardwaredetection fails (which it does if the disk controller driver is different from the original system), one could then have access to the ENTIRE kernel modules tree to be able to load up the proper driver and continue the restore.

If it's not possible to stick it in the bootable section of the image (due to space) it SHOULD be possible to take the kernel modules tree and create that as an ISO on the C and make that loop mountable as needed.

I got hit by this bug/defect/limitation, when designing a customer solution in a virtual environment and tried to transfer it over to real physical hardware, it had NO DRIVERS avail (no complete kernel modules tree), which resulting in me having to manually load the drivers in the virtual side before mondo-archiving so that they'd be available when booting the physical machine, but this was a hack and wasted numerous hours to get around a deficiency that should never have been present IMHO.

Hi,

I am using mondorescue for some time without any problems for backups and replication of local linux machines, thank you very much! However, now that the time has come to backup the laptop of my boss, problem appeared :(

I think I know what is causing it: I am trying to backup several partitions with the overall data size of approx. 80 GB to an NFS mount, but locally there is just 9 GB for scratch and tmp, and it seems that mondorescue wrongly checks if the partition on which tmp and scratch space are has enough space to store the whole amount of data that is being backed up.

Details: laptop has windows NTFS partition of 75 GB, and SuSE linux is installed on the rest of HDD, with 9 GB of empty space on Linux. Backup is done to an NFS mount. If windows partition is not backed up, no problems (i.e. small linux partition can be backed up successfully). If windows partition is included (-x /dev/sda2), I get "/dev/sda2: no such file" after I see in the log file that the number of slices is correctly calculated for /dev/sda2. This is misleading message and should be fixed (not enough space is more appropriate, although also not correct).

However, if I set scratch (-S) and tmp (-T) directory to be on the NFS mount (the same used for storing the backup iso images), then everything works, since on NFS mount there is enough space (200 GB+), wile on the local disk there is just 9 GB of free space. Of course, this is _very_ slow (15+ hours estimated), and in practice not feasible.

Now, I have verified that (with the size of iso images not specified, defaulting to CD size) tmp directory on NFS mount never grows over 150-170 MB, and scratch directory on NFS mount never over 650 MB (of course), which means that local scratch and tmp can be used easily, but for some reason mondorescue fails to realize that and gives up (this happens after backup of linux partitions is finished, at the start of the backup of windows partition as biggiefile).

Do you have any ideas how to easily fix this? Versions used:

mondo-2.2.4-1.suse10.2.i586.rpm mindi-busybox-1.2.2-3.suse10.2.i586.rpm mindi-1.2.4-1.suse10.2.i586.rpm

Thanks, Antun Balaz antun@…

As reported on mondo ML: ​http://sourceforge.net/mailarchive/forum.php?thread_name=1295604747763-2300816.post%40n3.nabble.com&forum_name=mondo-devel

In the mondorestore application under the "Storage Dir" form, the text entry for inputting the path to your ISO files seems to be limited to 51 characters. This is arrived via the following:

Run mondorestore select OK Select "Hard disk"

The form with the information:

Storage dir.

Please enter the full path name to the directory for your ISO images. Example: /mnt/raid0_0

is presented to the user, in the text input box I try to add a path greater than 51 characters and am not able to do so, The path gets truncated.

This is with version 2.2.4.

Best Regards, Bill

zeroconf (www.zeroconf.org) apparently adds an IP address from the 169.254.0.0/16 range to an interface. So, with zeroconf installed I get the following outout from 'ip addr':

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:11:d8:50:e0:80 brd ff:ff:ff:ff:ff:ff
    inet 169.254.134.104/16 brd 169.254.255.255 scope link eth0
    inet 192.168.1.213/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::211:d8ff:fe50:e080/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ieee1394 00:e0:18:00:00:ce:cf:54 brd ff:ff:ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

The interesting one here is 2: The 192.168.1.213 address is what is configured as a static address. 169.254.134.104 is what zeroconf adds.

Networking in general works fine with this. However, mondoarchive uses ifconfig to obtain the IP address for the NFS config. 'ifconfig' gives:

eth0      Link encap:Ethernet  HWaddr 00:11:D8:50:E0:80
          inet addr:169.254.134.104  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::211:d8ff:fe50:e080/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10514 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17528791 (16.7 MiB)  TX bytes:977510 (954.5 KiB)
          Interrupt:177

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:358 errors:0 dropped:0 overruns:0 frame:0
          TX packets:358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:20284 (19.8 KiB)  TX bytes:20284 (19.8 KiB)

which means it only gives the IP address configured by zeroconf. And that address is what is using during restore and of course doesn't work.

I am not 100% sure what to do here but don't think it is super urgent. I mainly wanted it documented somewhere - maybe we should also put it in the wiki ?

One interesting comment I saw is that apparently ifconfig is getting superseded by the ip command. Maybe we need at some stage replace ifconfig with ip.

Cheers, Andree

During diagnosis of a different problem, I was presented with an on-screen (console) message reading, in part...

sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `mkisofs -no-emul-boot -b isolinux.bin -boot-load-size 4 -boot-info-table -c boot.cat -o /backupMondo- (test) -Birch-061025@… -J -r -p MondoRescue? -publisher www.mondorescue.org -A Mondo_Rescue_GPL -V 1 . >> /var/log/mondo-archive.log 2>> /var/log/mondo-archive.log' Call to mkisofs to make ISO (ISO #1) ...failed ---promptdialogYN---1--- Failed to burn ISO #1. Retry?

However, these error messages didn't appear in the log. When I submitted the information to the mondo-devel list, I included both the (compressed) lot, and this snapshot of the screen (above).

It might be useful to make sure all error messages are echoed to the log, so sending you that log would be adequate for your further investigation.

During the compare operation, mondorescue only uses the mountlist from the source system. If the target system does not have the same mountlist, compare will failed. The proposal is to add an interactive mode to change the mountlist before doing the compare operation.

I am requesting the following enhancements to Mondo/Mindi?:

A live CD (or other method of creating this) that would scan the system for necessary drivers and such to create a custom, bootable USB disk with the necessary drivers for the DVD burner, etc. The USB disk would contain a backup-to-DVD solution that created a backup and burned bootable DVDs (DVDs just like Mondo's current DVD backups).

Just to be clear: I do not want to back up files to the USB drive -- I want to BOOT from the USB and burn backups to DVDs.

When I restore a backup to a new hard disk and let Mondo do the partioning and formatting, it uses 1024 as ext3 block size, but the original hard disk had 4096.

When dealing with very large files useless in a backup (aka a 22GB swap file e.g.) allow for their exclusion with -E or something similar.

mondo should support other type of NICs such as xenbrxx, vlanxx, ...

t also restores a few other empty directories which weren't selected in the file list. They seem to be consistent, in that I've done it twice and it restored the same 3 empty directories (note that they weren't empty on the original system). Since no unwanted files from those directories were restored I suppose that it's not really a big problem, but it is odd.

The unwanted directories restored in addition to what I asked for were:

/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur
/tmp
/var/lib/mysql

I've noticed that they seem to be coming from the biggiefiles section even though they weren't selected.

Done.
Reassembling large files      
	[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2397: OK, there are 5 biggiefiles in the archives
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 1 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2,)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2,
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 931bcc31faaebc228109f8f78c95f201
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 2 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2,)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2,
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = f9ba3e4c5d6b8daf10d5c47d4fcedc78
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 3 (/home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #6    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #7    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 1e4aa002fbebb935d4a185d708782b51
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /tmp/selected-files.txt --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /tmp/selected-files.txt (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 4 (/tmp/selected-files.txt)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #2    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #3    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #4    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #5    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #6    
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /tmp/selected-files.txt
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 841aec6a37f6d2d2b9991eb31f9f6fd2
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /var/lib/mysql/ibdata1 --- pih=NO
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /var/lib/mysql/ibdata1 (name isn't in biggielist subset)
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 5 (/var/lib/mysql/ibdata1)
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"'
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #0    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #1    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #2    
[...]	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3184    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3185    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3186    
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3187    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3187,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3188    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3188,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3189    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3189,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3190    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3190,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3191    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3191,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3192    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3192,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
	[Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3193    
update_progress_form_full(      I am now reassembling all the large files.     ,Working on file #5, slice #3193,         Please wait. This may take some time.       ) --- g_current_progress=3216; g_maximum_progress=3215
[Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now 
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /var/lib/mysql/ibdata1
		[Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 78161e8cd4e70e2c30ae89e5070f4ac0
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored 
[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2447: 5 biggiefiles in biggielist.txt; 5 biggiefiles processed today.
	[Main] mondorestore.c->restore_all_biggiefiles_from_stream#2470: mondorestore.c, restore_all_biggiefiles_from_stream, 2470: No biggiefiles selected. So, no biggie-EXATs to set.
Done.
	[Main] libmondo-stream.c->closein_tape#120: closein_tape() -- entering
	[Main] libmondo-stream.c->closein_tape#138: closein_tape() -- leaving
running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
		[Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0
running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
	[Main] libmondo-files.c->length_of_file#611: filename=/etc/raidtab
Unable to openin filename (No such file or directory)
running: ps  | grep " petris " | awk '{print $1;}' | grep -v "grep" > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran with res=256
running: kill `ps  | grep " petris " | awk '{print $1;}' | grep -v "grep"` > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec]
--------------------------------end of output------------------------------
...ran with res=256
	[Main] mondorestore.c->restore_everything#2716: restore_everything() --- leaving
Freeing memory formerly occupied by filelist
	[Main] libmondo-filelist.c->free_filelist#429: Finished freeing memory
	[Main] mondorestore.c->restore_to_live_filesystem#974: Tape : I don't need to unmount or eject the CD-ROM.
running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
umount: /mnt/cdrom: not mounted
--------------------------------end of output------------------------------
...ran with res=256
running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
/dev/st0: Input/output error
--------------------------------end of output------------------------------
...ran with res=256
		[Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0
running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
	[Main] mondorestore.c->main#3194: Still here. Yay.
running: rm -Rf /storage/mondo.tmp.MXRHQj/* > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
--------------------------------end of output------------------------------
...ran just fine. :-)
		[Main] libmondo-tools.c->unmount_boot_if_necessary#1309: starting
		[Main] libmondo-tools.c->unmount_boot_if_necessary#1316: leaving
	[Main] libmondo-files.c->register_pid#815: Unregistering PID
running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
umount: /mnt/cdrom: not mounted
--------------------------------end of output------------------------------
...ran with res=256
[Main] newt-specific.c->finish#406: Calling newtSuspend()

I want to use the "-n" option with mondoarchive, to write to an automounted nfs share. For instance, we have have a NAS appliance called pisrh11, which has space carved up for nfs shares. On our servers, we are using the automounter, which automatically maps shares on pishr11, based on entries in the /etc/auto_* files.

Here would be the automount file for application installed locally:

# more /etc/auto_apps
TRPperf		-rw	localhost:/export/appl/pkgs/&
pb              -rw     localhost:/opt/&   # PowerBroker
java            -rw     localhost:/export/appl/pkgs/&
AppManager      -rw     localhost:/export/appl/pkgs/AppManager/v8

Here is the master automount file which points to some NIS maps:

# more /etc/auto_master
/trprmt/logs    yp:auto.trprmt
/nfs            yp:auto.nfs
/apps		/etc/auto_apps

And here is the NIS entry for the mondoarchive shares:

# ypcat auto.nfs|grep Linux
-soft,bg,rw		pishr:/images_Linux/trp
-soft,bg,rw		pishr11:/images_Linux/trp

Here is the share mounted:

# pwd
/root
(piadm41)# cd /nfs/LinuxImages
(piadm41)# pwd
/nfs/LinuxImages
(piadm41)# df -k .
Filesystem           1K-blocks      Used Available Use% Mounted on
pishr:/images_Linux/trp
                     103257600   3244608 100012992   4% /nfs/LinuxImages
(piadm41)# mount|grep Linux
pishr:/images_Linux/trp on /nfs/LinuxImages type nfs (rw,soft,addr=10.22.214.26)

Thanks again.

while running mondoarchive I noticed this error.

---evalcall---E---
---evalcall---1---        Making catalog of /home
---evalcall---2--- TASK:  [*********...........]  44% done;  0:06 to go
---evalcall---E---
sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file
---evalcall---1---        Making catalog of /home
---evalcall---2--- TASK:  [***********.........]  53% done;  0:05 to go
---evalcall---E---

It may be due to this:

Under .java/.userprefs there were directories like below:

I deleted them and mondo ran OK.

~/.java/.userPrefs/_!'8!cg"n!#4!b@"v!(}=> ls
_!'0!}@"4!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l
_!'0!a@"u!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l
_!'0!}@"j!()!bw"z!&8!a@"u!'}!bw==
cache
display
_!(%!d@"v!(@!~@"f!(:!bw"1!()!}w"l
equations
_!'k!~!"f!(%!d@"v!(@!~@"f!(:!e@"u!':=
language
license
macros
_!'@!~@"m!'%!d@"s!(@!|w"j!'g!}@"y!(@!|w"k!'`!~g"h!(`!b!"0!(:=
portfolio
prefs
prefs.xml
proxy
watchscreens

Hey, I noticed that even if mondoarchive is running with exclude to some directories and exclude the NFS file systems, when the mondo is making the catalog, he is 'lstat'ing ALL the files including those to be excluded later.

The problem is that we have servers with NFS mount point that holds millions of millions of files and the lstat is taking too long ( + making the NFS server work very hard).

Is it possible somehow to change this behavior ?

mondoarchive could indeed Automagically toggle the -z flag when SELinux is on.

Hello,

I have system, which contains non standard filesystem partitions (informix data parts). Mondo can't backup them (ofcourse), he ignores them. When I want to clone system, he don't know about these partitions and I have to make them by hand. When cloning multiple machines, it is annoying. I resolved this by saving (sfdisk -d) for all drives in system, and in modified post-init, if they didn't match current setup, I ask to repartition them. I wish mondo can parttion them in the same fashion.

Moreover, it is philosophical that mondo should include two basic modes: restore to original system and clone system. In restore original, the system ramdisk & bootup process could be used to ensure correct module & device initialization, repartition drives to same configuration with NO questions :). In clone mode, there could be that nice features like inserting all modules, mountlist resizing and checking, many questions etc.

Thanks

running OpenSuse? 11.1 & 11.2 64

When using

/usr/sbin/mondoarchive -Vr -d /dev/sr0 -s 4480m -g

mondoarchive asked me what device to compare, even though I have it in the command line.

(report from Robert E Laughlin)

How to put the scratch dir on the NFS mount automatically (mount is done inside mondo - normally - so user has no way as of now to specify the creation of the scratch dir under that mount point, which would be useful in that case. From code it seems that scratchdir is created on the fly so should work.

Restoration is done by default for grub on sda (because multipath and GRUB found on sda, sdb, dm-2 => prefer to get a question at restore time + option in boot cli) Also useful for P2V.

hello, mondoarchive -OVN does not exclude unmounted automounts from the catalog, so it backs up the complete mountpoint as it gets mounted when the actual backup starts.

A scripted ls -l to the automount directories close before the backup does help but is not that nice!

The used versions are: mondo-3.0.2-1.sles10 mindi-busybox-1.18.5-1.sles10 mindi-2.1.3-1.sles10

kind regards Daniel Berglar

It would be interesting to validate the usge of MondoRescue with an SD card put in an HP ProLiant server to use it as a DR mecanism.

While it should'nt require any specific adaptation, it has never been tested so would at leat require that step to be performed.

Debian 8.4 - amd64 arch packages from deb ​ftp://ftp.mondorescue.org/debian 8 contrib UEFI system

trying to boot generated CD, but it failed with error message that ldlinux.c32 can't be found

Tried to copy all files form $scratch\EFI to $scratch (while backup is in progress) so I force ldlinux.c32 and configuration files to root dir on CD and evereything started to work again.

mindi - 3.0.2-1 mindi-busybox - 1.21.1-1 mondo - 3.2.2-1

After mondobackup complete, we are seeing this mount get left behind. It's small and tends to be over 90% full, which causes our monitoring software to create a ticket.

SLES 12 SP1

# rpm -qa | grep -i mondo
mondo-3.2.2-1.sles12.x86_64
perl-MondoRescue-3.2.2-1.sles12.noarch

# rpm -qa | grep -i mindi
mindi-busybox-1.21.1-1.sles12.x86_64
mindi-3.0.2-1.sles12.x86_64

# df | grep loop
/dev/loop0                                 110766  100996      9770  92% /tmp/syslinux.mnt.10184.0

I've never seen this behavior before. Help?

On Suse 10.1 kernel 2.6.xxx using switches -S /tmp -T /tmp the following directories get orphaned in /tmp

cd.xxxx

mondo.scratch.xxxx

tmp.mondo.xxxx

On RH9 not using those switches the diretories are not left behind.

The physical extent size for volume group isn't preserved but set to the default of 32MB. Not that it's a problem, just a note. (From "Chua, Alfred" <alfred.chua_at_hp.com>)

I'm running mondoarchive from cron. The output from cron is sent as email to the local root account. This size of this output is often larger than 1MB due to a large number of lines starting with "---evalcall---" or "---progress-form---". I suggest the addition of an option that suppresses these messages (i.e. 'non-interactive mode').

# /usr/sbin/mondoarchive --version
mondoarchive v2.0.9-780
$ uname -a
Linux mylinux 2.6.9-42.0.3.EL # 1 Fri Oct 6 05:59:54 CDT 2006 i686 i686 i386 GNU/Linux

Thanks for the great software Bruno.

Best regards, Andreas --

This will allow backing up systems offline as well as backing up Window based systems.

This defect was observed on 2.2.9.2 (RHEL5.4). It should be the same on other distro though.

The following errors are encountered when trying to restore the backup:

setfattr: proc: Operation not supported
setfattr: sys: Operation not supported

Due to that, the GUI restore phase does not seem to finalize properly for a lambda end-user (even if it may have no other impacts).

It has been observed in the filelist-7 that /proc and /sys were backed-up with the following xattr:

# file: proc
security.selinux=0x73797374656d5f753a6f626a6563745f723a70726f635f743a733000
===
# file: sys
security.selinux=0x73797374656d5f753a6f626a6563745f723a73797366735f743a733000

Even if /proc and /sys sub-files/sub-dirs are not backed-up, we should also fully remove /proc and /sys from the backup. I guess removing it from the backup would avoid that kind of issue at restore time.

Note that the WA to set -E "/proc /sys" to exclude them did not work for me.