Custom Query (684 matches)

Hello,

I have found quite an annoying defect which can impact the proper functionning of a server after restore.

The issue was observed on RHEL5.4. The issue is observed only with the -z flag.

Command-line to make the backup was:

mondoarchive -OVi -N -d /home/backup -E /home/backup -s 4480m -z

Before backup :
===============

[root@lagrave /]# ll /usr/bin/sudo

---s--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo

After restore (if -z flag used for backup):
===============

[root]# ll /usr/bin/sudo

---x--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo

After restore (if -z flag was not used for backup):
===============

[root]# ll /usr/bin/sudo

---s--x--x 2 root root 140804 Apr 14 2009 /usr/bin/sudo


What we observe is that we loose the 's' attribute if the -z flag is used at backup time.

It has quite an impact since we can not use anylonger /usr/bin/sudo and possibly other commands after restore :

[ocadmin]$ sudo
sudo: must be setuid root

The issue seems to be lying in the fact that 'acl_list*' files are used to backup attributes only with the -z flag. Those 'acl_list*' files do not seem to backup properly the 's' attribute.

As an example for /usr/bin/sudo, we see that the associated acl_list file contains 'x' attribute instead of 's': ====================
# file: usr/bin/sudo # owner: root # group: root user::--x group::--x other::--x ====================

I have run mondoarchive (mondo-2.2.9.2-1.rhel5) several times on two separate machines with the following command line:

mondoarchive -OizNGg -d /backup -s 4480m -p hostname-date +%d-%b-%Y -E "/backup /var/lib/backuppc /var/named/chroot/proc" -S/backup -T/backup on uname -a:

Linux server1 2.6.18-164.10.1.el5.centos.plus #1 SMP Fri Jan 8 16:54:35 EST 2010 i686 i686 i386 GNU/Linux

Everything goes well for awhile (30mins or so) but in the 'Archiving regular files' section it simply hangs. Top indicates that mondoarchive is not doing anything and it just sits there for hour after hour. There is no error message in the mondoarchive.log file. When I ran it for CD size ISOs, it happily created four CD ISOs, but seemingly will not create a DVD size ISO.

I have included the log file.

Unable to restore from Ubuntu 10.04 AMD64 on 2Tb Raid using mindi_2.0.7.5-1_amd64, mindi-busybox_1.7.3-1_amd64 and mindi_2.0.7.5-1_amd64

procedure to reproduce this error.

Install Ubuntu 10.04 AMD 64 on RAID 2x2Tb with boot

Model: VMware, VMware Virtual S (scsi) Disk /dev/sda: 2147GB Sector size (logical/physical): 512B/512B Partition Table: gpt

Number Start End Size File system Name Flags

1 1049kB 2097kB 1049kB bios_grub 2 2097kB 5002MB 5000MB linux-swap(v1) 3 5002MB 2147GB 2142GB ext4 raid

Model: VMware, VMware Virtual S (scsi) Disk /dev/sdb: 2147GB Sector size (logical/physical): 512B/512B Partition Table: gpt

Number Start End Size File system Name Flags

1 1049kB 2097kB 1049kB bios_grub 2 2097kB 5002MB 5000MB linux-swap(v1) 3 5002MB 2147GB 2142GB ext4 raid

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [ra id10] md0 : active raid1 sda3[0] sdb3[1]

2092266432 blocks [2/2] [UU] [==>..................] resync = 12.6% (265176576/2092266432) finish=147.

6min speed=206252K/sec

unused devices: <none> After installation

1 apt-get install mkisofs cdrecord buffer syslinux dvd+rw-tools mtools 2 apt-get install bindutils 4 apt-get install bind9

13 dpkg -i mondo_2.2.9.4-1_amd64.deb mindi-busybox_1.7.3-1_amd64.deb mindi_2.0.7.5-1_amd64.deb 17 apt-get -f install

mondoarchive (ran with no problems)

place iso on network create new vmware machine with same specs boot from iso

mode=nuke mindi boot ok mountlist analized. Result: Gap prior to /dev/sda2. 426Mb over-allocated on /dev/sda. (and sdb) switch to intracitve Mode? yes mount list gives /dev/md0 / ext4 and /dev/sda2 swap swap 2048000 and /dev/sdb2 swap swap 2048000 mount list incorrect. 1) can not continue to restore.

2) after building the /dev/md0 myself and restoring the data and update-initramfs -u it does not boot it runs into busybox. /etc/mdproc speaks about /dev/md_d0 instead of /dev/md0.

Can you fix this? Please don't hesitate to contact me if I can be of any help.