Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Restoring the entire ETC directory in similar hardware

  1. #1
    Join Date
    Mar 2010
    Posts
    28

    Default Restoring the entire ETC directory in similar hardware

    We are looking for a solution that allows us to restore a servers "identity" in the event of hardware failure...ie Name, IP address, dhcpd, named configs etc.

    We have ISO images of the appliance images that contains all the software and stuff. There is no real data on these servers.

    If we backup the entire ETC directory and perhaps the /var/lib can we simply restore that and get everything back?

    What concerns me is how some versions of Suse use UUID for the network config and the mounts points.

    Has anyone tried this?

  2. #2
    Join Date
    Aug 2008
    Location
    Behind the 8 ball
    Posts
    116

    Default Re: Restoring the entire ETC directory in similar hardware

    Backing up /etc/ and restoring it back down after a hardware replacement will work fine.

    Just be sure to avoid using "disk by-id" entries in things like the fstab.

    For example don't have something like this in your fstab
    Code:
    /dev/disk/by-id/scsi-36001e4f0215a65000f4ea6a604c134b6-part3 /                    ext3       acl,user_xattr        1 1
    Use this
    Code:
    /dev/sda3 /                    ext3       acl,user_xattr        1 1
    What are you planning on backing up in /var/lib?

    Good luck,
    Hiatt

  3. #3
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Restoring the entire ETC directory in similar hardware

    On 2011-05-04 18:36, mww wrote:

    > If we backup the entire ETC directory and perhaps the /var/lib can we
    > simply restore that and get everything back?


    And perhaps the grub configuration in /boot.

    However, what you need is a script that backups everything that changed
    from the initial configuration, except the data directories that do not
    interest you.

    > What concerns me is how some versions of Suse use UUID for the network
    > config and the mounts points.


    You can use other things, like LABEL, instead of UUID. Do not use device
    names like /dev/sda.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  4. #4
    Join Date
    Aug 2008
    Location
    Behind the 8 ball
    Posts
    116

    Default Re: Restoring the entire ETC directory in similar hardware

    After you restore /etc you should also clear out the udev rule for your network devices if you replace a NIC or a motherboard with an onboard NIC

    Code:
    cat /dev/null > /etc/udev/rules.d/70-persistent-net.rules

  5. #5

    Default Re: Restoring the entire ETC directory in similar hardware

    jthiatt08 wrote:
    > Just be sure to avoid using "disk by-id" entries in things like the
    > fstab.
    >
    > For example don't have something like this in your fstab
    >
    > Code:
    > --------------------
    >
    > /dev/disk/by-id/scsi-36001e4f0215a65000f4ea6a604c134b6-part3 /

    ext3 acl,user_xattr 1 1
    >
    > --------------------
    >
    >
    > Use this
    >
    > Code:
    > --------------------
    >
    > /dev/sda3 / ext3 acl,user_xattr 1 1
    >
    > --------------------



    Carlos E. R. wrote:
    > On 2011-05-04 18:36, mww wrote:
    >
    >> If we backup the entire ETC directory and perhaps the /var/lib can we
    >> simply restore that and get everything back?

    >
    > And perhaps the grub configuration in /boot.
    >
    > However, what you need is a script that backups everything that changed
    > from the initial configuration, except the data directories that do not
    > interest you.
    >
    >> What concerns me is how some versions of Suse use UUID for the network
    >> config and the mounts points.

    >
    > You can use other things, like LABEL, instead of UUID. Do not use device
    > names like /dev/sda.


    I think it's time for a review of disk/partition identification to make
    it clearer.

    jthiatt08 is correct in saying not to use disk-by-id, which
    unfortunately is what opensuse uses by default. That's a value tied to
    the particular disk that's in use.

    But jthiatt08 is wrong, as carlos says, to suggest using /dev/sda. Those
    names should no longer be used because of the way the linux kernel scans
    disks nowadays. They can theoretically change between boots and
    certainly on apparently identical systems that have a minor difference.

    LABEL is good. You can assign arbitrary human-readable names.

    UUID is also good. The system assigns a meaningful but unreadable
    identifier, but this can be copied from disk to disk and system to
    system. It's what Ubuntu uses by default. The only problem is that it
    can get pretty confusing.

    As for the nitty gritty details, there's no substitute for experiment.
    Set up your proposed method and test it a few times

  6. #6
    Join Date
    Aug 2008
    Location
    Behind the 8 ball
    Posts
    116

    Default Re: Restoring the entire ETC directory in similar hardware

    But jthiatt08 is wrong, as carlos says, to suggest using /dev/sda. Those
    names should no longer be used because of the way the linux kernel scans
    disks nowadays. They can theoretically change between boots and
    certainly on apparently identical systems that have a minor difference.
    That's interesting.
    I have been managing 1200+ Linux servers for the past 4 years and I've never seen this behavior.
    All the servers are have identical hardware and even have an external USB drive attached.
    They always boot to the device that I specified in the fstab and the menu.lst.
    What devices, other than /dev/sdX, will the kernel point me to?
    It sounds like I will need to make changes to all the systems to prevent a boot failure.

    @mww - The more I think about it, I think you should scrap the idea of backing up directories.
    Identify which files need to change on the system and then write a script to change those files to your liking.


    Good luck,
    Hiatt

  7. #7
    Join Date
    Jun 2008
    Location
    Earth - Denmark
    Posts
    10,730

    Default Re: Restoring the entire ETC directory in similar hardware

    On 05/05/2011 05:06 PM, jthiatt08 wrote:
    >
    > That's interesting.
    > I have been managing 1200+ Linux servers for the past 4 years and I've
    > never seen this behavior.
    >


    i've not seen it either (i'm on 11.3) so *perhaps* it is in 11.4 (and
    kernel), and we get to sweat it out for a year or two before it makes it
    into a SLES SP.....maybe..

    things do change...

    --
    CAVEAT: http://is.gd/bpoMD
    [openSUSE11.3 + KDE4.5.5 + Firefox3.6.17 + Thunderbird3.1.10 via NNTP]
    HACK Everything -> http://www.youtube.com/watch?v=j5b4CCe9pS8&NR=1

  8. #8
    Join Date
    Mar 2010
    Posts
    28

    Default Re: Restoring the entire ETC directory in similar hardware

    Thanks for all the tips.

    I'll look at using label or uuid.

  9. #9
    Join Date
    Aug 2008
    Location
    Behind the 8 ball
    Posts
    116

    Default Re: Restoring the entire ETC directory in similar hardware

    You are right DenverD, things do change.
    I'm glad I learned about this change now, it would have really bit me in the future.
    I will be using UUID from now on.

    Thanks,
    Hiatt

  10. #10
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    16,285

    Default Re: Restoring the entire ETC directory in similar hardware

    The problem is in devices with plug and play type situation with pluggable drives. If you have a stable drive system /dev/sda notation is fine . USB and mixing IDE and SATA drive is also another good way get unstable BIOS labeling. In a production environment this should never be a problem if things are done right. /dev/sda notation is useful in cloning situation where you have firm control over disk discovery order.

    If we bother to label the partitions LABEL_ID is the best way to keep things straight.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •