Two SCO machines . Backup server os 5.06 Main server 5.07.

In cron I have
copy -rom /nfs-mounted-server/directory /here/safe (you know what I mean)

I am attempting to copy a directory or two so we have a complete working
server backup in case the main server goes down. I do not mind it being a
few hours out of date. The staff know the backup will in effect be read
only.

This may not be the best way to copy or have duplicate files to another
server, as I want all permissions and ownerships copied as well. copy
command in cron just makes everything owned by root and sys.

Better cron backup ideas? Of course the main server does a cpio to tape of
the entire system. I want the staff to be able to click another system
should the main server go down and their engineer is on hols (ie me).

Thanks

Dr Gerard Bulger
--
http://www.careprovider.com

On Sun, 11 Apr 2004 20:48:58 +0100, "G3WIP" <g3wip@deadspam.co.uk>
wrote:

>Two SCO machines . Backup server os 5.06 Main server 5.07.
>
>In cron I have
>copy -rom /nfs-mounted-server/directory /here/safe (you know what I mean)
>
>I am attempting to copy a directory or two so we have a complete working
>server backup in case the main server goes down. I do not mind it being a
>few hours out of date. The staff know the backup will in effect be read
>only.
>
>This may not be the best way to copy or have duplicate files to another
>server, as I want all permissions and ownerships copied as well. copy
>command in cron just makes everything owned by root and sys.
>
>Better cron backup ideas? Of course the main server does a cpio to tape of
>the entire system. I want the staff to be able to click another system
>should the main server go down and their engineer is on hols (ie me).

rsync is a great solution for what you want to do. Using rsync will
reduce the amount of actual copying required. Depending on the size of
your data you may be able to rsync as often as once an hour.

Problem: Depending on what you are copying you may end up with invalid
data, e.g., if you are backing up database files. Have you taken this
into consideration?

Alternatively, you can consider using shared storage such as an
external disk with a dual-ported SCSI interface. When using this
method your backup server will have access to the same data that was
being used by the primary system. This basically gives you a warm
backup server.

---
Puryear Information Technology, LLC
Baton Rouge, LA
225-343-3056
http://www.puryear-it.com

Author of "Best Practices for Managing Linux and UNIX Servers"
Download your free copy:
http://www.puryear-it.com/manage-linux.htm

G3WIP typed (on Sun, Apr 11, 2004 at 08:48:58PM +0100):
| Two SCO machines . Backup server os 5.06 Main server 5.07.
|
| In cron I have
| copy -rom /nfs-mounted-server/directory /here/safe (you know what I mean)
|
| I am attempting to copy a directory or two so we have a complete working
| server backup in case the main server goes down. I do not mind it being a
| few hours out of date. The staff know the backup will in effect be read
| only.
|
| This may not be the best way to copy or have duplicate files to another
| server, as I want all permissions and ownerships copied as well. copy
| command in cron just makes everything owned by root and sys.
|
| Better cron backup ideas? Of course the main server does a cpio to tape of
| the entire system. I want the staff to be able to click another system
| should the main server go down and their engineer is on hols (ie me).

Use rdist instead of copy.

And cpio to tape is a *terrible* backup strategy.
Use BackupEDGE or LoneTar.

--
JP

Thanks. Lots of ideas there.
J.P: I would be interested to know what is so awful about cpio to tape. The
answers may be amusing and alarming


--
http://www.careprovider.com

"Jean-Pierre Radley" <jpr@jpr.com> wrote in message
news:20040412005136.GA11497@jpradley.jpr.com...
> G3WIP typed (on Sun, Apr 11, 2004 at 08:48:58PM +0100):
> | Two SCO machines . Backup server os 5.06 Main server 5.07.
> |
> | In cron I have
> | copy -rom /nfs-mounted-server/directory /here/safe (you know what I
mean)
> |
> | I am attempting to copy a directory or two so we have a complete working
> | server backup in case the main server goes down. I do not mind it being
a
> | few hours out of date. The staff know the backup will in effect be read
> | only.
> |
> | This may not be the best way to copy or have duplicate files to another
> | server, as I want all permissions and ownerships copied as well. copy
> | command in cron just makes everything owned by root and sys.
> |
> | Better cron backup ideas? Of course the main server does a cpio to
tape of
> | the entire system. I want the staff to be able to click another system
> | should the main server go down and their engineer is on hols (ie me).
>
> Use rdist instead of copy.
>
> And cpio to tape is a *terrible* backup strategy.
> Use BackupEDGE or LoneTar.
>
> --
> JP

G3WIP typed (on Mon, Apr 12, 2004 at 02:13:07PM -0700):

| "Jean-Pierre Radley" <jpr@jpr.com> wrote in message
| news:20040412005136.GA11497@jpradley.jpr.com...
|
| > G3WIP typed (on Sun, Apr 11, 2004 at 08:48:58PM +0100):
| >
| > | Two SCO machines . Backup server os 5.06 Main server 5.07.
| > |
| > | In cron I have copy -rom /nfs-mounted-server/directory /here/safe
| > | (you know what I mean)
| > |
| > | I am attempting to copy a directory or two so we have a complete
| > | working server backup in case the main server goes down. I do not
| > | mind it being a few hours out of date. The staff know the backup
| > | will in effect be read only.
| > |
| > | This may not be the best way to copy or have duplicate files to
| > | another server, as I want all permissions and ownerships copied as
| > | well. copy command in cron just makes everything owned by root and
| > | sys.
| > |
| > | Better cron backup ideas? Of course the main server does a cpio
| > | to tape of the entire system. I want the staff to be able to
| > | click another system should the main server go down and their
| > | engineer is on hols (ie me).
| >
| > Use rdist instead of copy.
| >
| > And cpio to tape is a *terrible* backup strategy. Use BackupEDGE or
| > LoneTar.

I reverted your the top-posting. :-(

| Thanks. Lots of ideas there.

Lots?? I posted one idea, one observation, and one suggestion. That's
lots??

| J.P: I would be interested to know what is so awful about cpio to tape. The
| answers may be amusing and alarming

With a cpio backup, you do NOT have a bit-level verified backup, and you
are NOT able to READILY restore the machine in case of hardware failure.

--
JP

On Mon, 12 Apr 2004 14:13:07 -0700, "G3WIP" <g3wip@deadspam.co.uk>
wrote:

>Thanks. Lots of ideas there.
>J.P: I would be interested to know what is so awful about cpio to tape. The
>answers may be amusing and alarming

Would J.L. be ok? The problem with cpio, tar, pax, dd, and such is
that threre's no mechanism for verifying that your copy arrived in one
piece, or that your tape drive didn't "error correct" the data into
oblivion. Good, fast, cheap. Pick two.

http://aplawrence.com/Reviews/supertar.html

--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com

In article <esgm705rk3sfkvdp3s8vbetsefkge5777o@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>On Mon, 12 Apr 2004 14:13:07 -0700, "G3WIP" <g3wip@deadspam.co.uk>
>wrote:

>>Thanks. Lots of ideas there.

>>J.P: I would be interested to know what is so awful about cpio
>>to tape. The answers may be amusing and alarming

>Would J.L. be ok? The problem with cpio, tar, pax, dd, and such is
>that threre's no mechanism for verifying that your copy arrived in one
>piece, or that your tape drive didn't "error correct" the data into
>oblivion. Good, fast, cheap. Pick two.

>http://aplawrence.com/Reviews/supertar.html

And in cpio vs tar, the latter is pretty basic in construction,
more like a huge concantentaion of files written consecutively.
As such it's easier to reconstruct a broken tar file with system
tools than it is a cpio file.

And in addition to Jeff's comment on a drive 'error correcting' the
data, there is also the other possibility.

Data can [not often but it can] be corrupted from the time it is
read from the disk and before it is delivered to the tape
controller. Then when the tape controller gets it, it builds a
crc/checksum on data with errors, so if you if you think a tape is
good just by reading end to end to see if there are no CRC errors,
you have what you >think< is a good backup, when in reality it is
corrupt.

The supertar solutions are the only way to go except for the
dedicated hacker [using the original definition] who builds their
own bit-level verifications routines, or finds the source on
the 'net for one. In the Olden Dayze when BackupEdge and LoneTar
were not available on one platform I used, and old SysV.2 as I
recall, and I had a program from alt.sources written by Warren
Tucker, and I used it for bit-level verifies for floppy saves.

Not worth in today's world.

Bill

--
Bill Vermillion - bv @ wjv . com