关于FB系统的备份

今天下午恢复了系统,把以前 备份的 /usr  /var /etc 都恢复了回去. 不过发现,有一半的服务已经启动不起来了

 

都是提示

 

/libexec/ld-elf.so.1: Shared object "libz.so.4" not found, required by "searchd"

在  ld-elf.so.1 里找不到库

 

我想看到底是缺了那些库

 

ldd /usr/local/sphinx/bin/searchd

 

 

显示如下:

 

libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x281ad000)
        libz.so.4 => not found (0x0)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2823f000)
        libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x28334000)
        libthr.so.3 => /lib/libthr.so.3 (0x28354000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28369000)
        libm.so.5 => /lib/libm.so.5 (0x2845d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x28477000)
        libc.so.7 => /lib/libc.so.7 (0x28482000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x2859a000)
        libz.so.5 => /lib/libz.so.5 (0x285b3000)

 

原来是 libz.so.4 找不到了.  估计本来是安装程序时候自动存放到 /lib 里了,而 lib 我没备份

 

总结:

以后,备份还需要多备份一个 /lib目录.

和备份  libexec/ld-elf.so.1 文件.

 

下面付上 man ld-elf.so.1 的解释

 

 

DESCRIPTION
     The ld-elf.so.1 utility is a self-contained shared object providing run-
     time support for loading and link-editing shared objects into a process'
     address space.  It is also commonly known as the dynamic linker.  It uses
     the data structures contained within dynamically linked programs to
     determine which shared libraries are needed and loads them using the
     mmap(2) system call.

     After all shared libraries have been successfully loaded, ld-elf.so.1
     proceeds to resolve external references from both the main program and
     all objects loaded.  A mechanism is provided for initialization routines
     to be called on a per-object basis, giving a shared object an opportunity
     to perform any extra set-up before execution of the program proper
     begins.  This is useful for C++ libraries that contain static construc-
     tors.