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
Printable View
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
On Tue, 26 Jun 2007 17:18:14 -0700
Who Cares <ddorman@sympatico.ca> wrote:
[color=blue]
> 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
> [/color]
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
Who Cares wrote:
[color=blue]
> 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[/color]
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
-------------------------------------------------
Who Cares wrote:[color=blue]
> 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.[/color]
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.
Who Cares wrote:[color=blue]
> 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.[/color]
[url]http://en.opensuse.org/StoreBackup[/url]
houghi
--
Always listen to experts. They'll tell you what can't be done,
and why. Then do it.
-- Heinlein : Time Enough For Love
On Wed, 27 Jun 2007, Chris Cox wrote:-
<snip>
[color=blue]
>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.[/color]
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:
<URL:http://www.davjam.org/~davjam/rsync.example.htm>
[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: [url]http://www.distributed.net/[/url]
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
David Bolt wrote:[color=blue]
> On Wed, 27 Jun 2007, Chris Cox wrote:-
>
> <snip>
>[color=green]
>> 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.[/color]
>
> 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.[/color]
:) 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.
On Thu, 28 Jun 2007, Chris Cox wrote:-
[color=blue]
>David Bolt wrote:[/color]
[color=blue][color=green]
>> 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.[/color]
>
>:) 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.[/color]
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: [url]http://www.distributed.net/[/url]
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