Backup advise - Suse

This is a discussion on Backup advise - Suse ; OpenSUSE 10.2 KDE 3.5.7 43.1 VMware 6 Can anyone suggest a fool proof backup package that will backup / / home and a 15GB VMwae partition. Many thanks...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Backup advise

  1. Backup advise

    OpenSUSE 10.2
    KDE 3.5.7 43.1
    VMware 6

    Can anyone suggest a fool proof backup package that will backup / /
    home and a 15GB VMwae partition.

    Many thanks


  2. Re: Backup advise

    On Tue, 26 Jun 2007 17:18:14 -0700
    Who Cares wrote:

    > OpenSUSE 10.2
    > KDE 3.5.7 43.1
    > VMware 6
    >
    > Can anyone suggest a fool proof backup package that will backup / /
    > home and a 15GB VMwae partition.
    >
    > Many thanks
    >

    Hi
    I use rsync to copy off to a usb drive home including six different
    vmware5.5 systems. Initial rsync takes awhile and if you have used a
    vmware machine between backups.
    For the system files I use iBackup of to a NAS.

    --
    Cheers Malcolm °¿° (Linux Counter #276890)
    SLED 10.0 x86_64 Kernel 2.6.16.46-0.14-smp
    up 1 day 4:30, 3 users, load average: 0.10, 0.04, 0.01

  3. Re: Backup advise

    Who Cares wrote:

    > OpenSUSE 10.2
    > KDE 3.5.7 43.1
    > VMware 6
    >
    > Can anyone suggest a fool proof backup package that will backup / /
    > home and a 15GB VMwae partition.
    >
    > Many thanks


    I use bacula an a used adic faststor22 dlt-lib for backup. I. e. a
    DLT7000-Tape can store at least 35 GB (without compression). This is a
    quite secure way, better than mirroring to other harddisks (that will get
    broken as well when your pc will be killed by a lightning an the follwing
    overvoltage...). So a Nas-box, a simple hd-raid isn't a alternative to a
    tape backup.

    Kind regards

    Rolf


    -------------------------------------------------
    Without destination the journey will be endless
    -------------------------------------------------



  4. Re: Backup advise

    Who Cares wrote:
    > OpenSUSE 10.2
    > KDE 3.5.7 43.1
    > VMware 6
    >
    > Can anyone suggest a fool proof backup package that will backup / /
    > home and a 15GB VMwae partition.


    rsync, tar, etc. will work.

    However, realize that even with rsync, ALL 15GB of your VMware
    image will be backed up EVERY time since the changes are
    abstracted inside of a virtualized filesystem. You may want
    to have your guests back themselves up and only do the whole
    VMware image some of the time.

    If you know what you are doing, you can have even Windows
    guests under VMware backing up via rsync.

  5. Re: Backup advise

    Who Cares wrote:
    > OpenSUSE 10.2
    > KDE 3.5.7 43.1
    > VMware 6
    >
    > Can anyone suggest a fool proof backup package that will backup / /
    > home and a 15GB VMwae partition.


    http://en.opensuse.org/StoreBackup

    houghi
    --
    Always listen to experts. They'll tell you what can't be done,
    and why. Then do it.
    -- Heinlein : Time Enough For Love

  6. Re: Backup advise

    On Wed, 27 Jun 2007, Chris Cox wrote:-



    >However, realize that even with rsync, ALL 15GB of your VMware
    >image will be backed up EVERY time since the changes are
    >abstracted inside of a virtualized filesystem.


    It won't be all the 15GB, just what's changed. How much is actually
    transferred will depend on how much use the virtual drive is written to,
    how "full" it is, if access times are remembered, etc. and how often the
    backup is made.

    As one example, here's the /etc/fstab for one of my 10.2 machines:

    /dev/hda1 /boot ext2 acl,user_xattr 1 2
    /dev/hda3 / ext3 acl,user_xattr 1 1
    /dev/hda8 /home ext3 acl,user_xattr 1 2
    /dev/hda7 /opt ext3 acl,user_xattr 1 2
    /dev/hda9 /tmp ext3 acl,user_xattr 1 2
    /dev/hda5 /usr ext3 acl,user_xattr 1 2
    /dev/hda6 /var ext3 acl,user_xattr 1 2
    /dev/hda10 /usr/local ext3 acl,user_xattr 1 2
    /dev/hda11 /usr/src ext3 acl,user_xattr 1 2
    /dev/hda12 /var/log ext3 acl,user_xattr 1 2
    /dev/hda13 /local ext3 acl,user_xattr 1 2
    /dev/hda14 /suse ext2 ro,acl,user_xattr 1 2

    Of these, /boot will rarely alter, as would /suse[0]. /opt, /usr and /
    will alter when packages are installed. /home, /tmp and /var/log will
    alter often. The remaining ones will alter when I do some specific
    actions[1].

    If /dev/hda was a virtual drive, and I was to use rsync to make a
    "backup" of it, the first time everything would be copied. After that
    rsync wouldn't need to copy /suse. It wouldn't need to copy /boot,
    unless I'd installed a new kernel, or changed the boot options. /opt and
    /usr may or may have some changes, especially if there was some new
    software added.

    As another example, if you have more than one machine available, you can
    see this in action quite easily by basically duplicating the steps I
    describe here:




    [0] /suse holds a copy of the 10.2 DVD, so needs no journal and doesn't
    need to be writeable.

    [1] e.g. building packages will change /var and /usr/src, adding scripts
    to /usr/local/(s)bin, or writing something to /local so it can be used
    by other users.

    Regards,
    David Bolt

    --
    Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/
    RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit
    RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit
    TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a5 32bit

  7. Re: Backup advise

    David Bolt wrote:
    > On Wed, 27 Jun 2007, Chris Cox wrote:-
    >
    >
    >
    >> However, realize that even with rsync, ALL 15GB of your VMware
    >> image will be backed up EVERY time since the changes are
    >> abstracted inside of a virtualized filesystem.

    >
    > It won't be all the 15GB, just what's changed. How much is actually
    > transferred will depend on how much use the virtual drive is written to,
    > how "full" it is, if access times are remembered, etc. and how often the
    > backup is made.


    Again, it's a virtual filesystem in a large file. Changes
    to the virtual filesystem will result is almost all of the 15GB
    being backed up EVERY time. I speak from experience on this.
    I'm talking about backing up the large *.vmdk files that a VMware
    guest uses.

  8. Re: Backup advise

    On Thu, 28 Jun 2007, Chris Cox wrote:-

    >David Bolt wrote:


    >> It won't be all the 15GB, just what's changed. How much is actually
    >> transferred will depend on how much use the virtual drive is written to,
    >> how "full" it is, if access times are remembered, etc. and how often the
    >> backup is made.

    >
    > Again, it's a virtual filesystem in a large file. Changes
    >to the virtual filesystem will result is almost all of the 15GB
    >being backed up EVERY time. I speak from experience on this.
    >I'm talking about backing up the large *.vmdk files that a VMware
    >guest uses.


    Were you using the same machine to store both the backups and the
    original file? If so, rsync defaults to using --whole-file and so will
    copy the entire file. This is one of the things I'm not too keen upon,
    as I wrote a backup script to backup specific files to an external drive
    and it was only after reading the man page that I found out why it was
    transferring the entire file, rather than just the changed bits.
    Eventually, I decided to pretend the file was going to another system,
    even though it was actually stored on the same host.

    If you're using separate machines, I can't see why the entire virtual
    drive would be transferred, as that doesn't happen when I try it.

    Below is another, and much more reasonable example using my 10.3 test
    "machine". In this case, I transferred the 8GB virtual drive from one
    machine to another, started up the virtual machine and rebuilt a total
    of 69 out of 72 RPM packages[0], closed the virtual machine and then
    transferred the virtual drive again. As you can see, not all the virtual
    drive was transferred.

    ===== start snippet here =====
    davjam@my-ste /cygdrive/e/Emulators/Testbed
    $ rsync -avv --stats --progress --partial "SUSE Linux.flat.vmdk" adder.davjam.org::local2/
    opening tcp connection to adder.davjam.org port 873
    opening connection using --server -vvlogDtpr --partial . local2/
    building file list ...
    1 file to consider
    SUSE Linux.flat.vmdk
    8590417920 100% 5.80MB/s 0:23:33 (1, 100.0% of 1)
    total: matches=0 tag_hits=0 false_alarms=0 data=8590417920

    rsync[2300] (sender) heap statistics:
    arena: 196608 (bytes from sbrk)
    ordblks: 3 (chunks not in use)
    smblks: 0
    hblks: 0 (chunks from mmap)
    hblkhd: 327680 (bytes from mmap)
    allmem: 524288 (bytes from sbrk + mmap)
    usmblks: 851968
    fsmblks: 0
    uordblks: 471424 (bytes used)
    fordblks: 52864 (bytes free)
    keepcost: 48832 (bytes in releasable chunk)

    Number of files: 1
    Number of files transferred: 1
    Total file size: 8590417920 bytes
    Total transferred file size: 8590417920 bytes
    Literal data: 8590417920 bytes
    Matched data: 0 bytes
    File list size: 83
    File list generation time: 0.003 seconds
    File list transfer time: 0.001 seconds
    Total bytes sent: 8591466693
    Total bytes received: 38

    sent 8591466693 bytes received 38 bytes 6078151.21 bytes/sec
    total size is 8590417920 speedup is 1.00
    davjam@my-ste /cygdrive/e/Emulators/Testbed

    $ rsync -avv --stats --progress --partial "SUSE Linux.flat.vmdk" adder.davjam.org::local2/
    opening tcp connection to adder.davjam.org port 873
    opening connection using --server -vvlogDtpr --partial . local2/
    building file list ...
    1 file to consider
    SUSE Linux.flat.vmdk
    8590417920 100% 8.41MB/s 0:16:13 (1, 100.0% of 1)
    total: matches=86190 tag_hits=393460739 false_alarms=9765 data=602420000

    rsync[2684] (sender) heap statistics:
    arena: 262144 (bytes from sbrk)
    ordblks: 3 (chunks not in use)
    smblks: 0
    hblks: 0 (chunks from mmap)
    hblkhd: 655360 (bytes from mmap)
    allmem: 917504 (bytes from sbrk + mmap)
    usmblks: 5767168
    fsmblks: 0
    uordblks: 891792 (bytes used)
    fordblks: 25712 (bytes free)
    keepcost: 21680 (bytes in releasable chunk)

    Number of files: 1
    Number of files transferred: 1
    Total file size: 8590417920 bytes
    Total transferred file size: 8590417920 bytes
    Literal data: 602420000 bytes
    Matched data: 7987997920 bytes
    File list size: 83
    File list generation time: 0.017 seconds
    File list transfer time: 0.002 seconds
    Total bytes sent: 602839133
    Total bytes received: 741558

    sent 602839133 bytes received 741558 bytes 529224.63 bytes/sec
    total size is 8590417920 speedup is 14.23

    davjam@my-ste /cygdrive/e/Emulators/Testbed
    ===== end snippet here =====

    From the above, less than 600MB of the 8GB "drive" is transferred.


    [0] The end results of the RPM building process failing is to leave the
    partially compiled sources in /usr/src/packages/BUILD , the spec file in
    SPECS , the script that failed in /var/tmp and, if the process actually
    failed while building the actual RPM, the files that would be installed
    under /var/tmp/$PACKAGE_BUILD_ROOT.

    Regards,
    David Bolt

    --
    Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/
    RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit
    RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit
    TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a5 32bit

+ Reply to Thread