[Arlo]

I'm thinking of upgrading my BW G3 from ASIP to OX Server, but of course Retrospect isnt native yet. What backup tools (if any) does Server ship with? Are there device drivers for assorted DLTs? Thanks..
Arlo

[Rolling Musubi]

To date, there are no non-beta backup solutions available for OS X Server 10.0 which is a rather significant issue for many who require such a solution before being able to deploy the OS in a production environment. Dantz is likely the closest to providing a solution but I'm hopeful that Veritas will consider entering this space for OS X (more competition, the better).

[Arlo]

Originally posted by Rolling Musubi:
To date, there are no non-beta backup solutions available for OS X Server 10.0 which is a rather significant issue for many who require such a solution before being able to deploy the OS in a production environment. Dantz is likely the closest to providing a solution but I'm hopeful that Veritas will consider entering this space for OS X (more competition, the better).

Apple's OS X Server site specifically states Retrospect client beta as working for it...yet Retrosepct's site explicitly states that it does not support OS X Server. I'm not sure if this means if it works and they wont support it, or it doesn't work period? Ack. I guess only one way to find out...

[utidjian]

You might want to check out "dump", see "man dump" for more details. Also "man rmt".

dump can certainly be set up to backup to a another HDD. Tape support is another matter.

-DU-...etc...

[Alex Duffield]

Could you not just mount the server volume im OS9 and use Retrospect to back up the drive??? Assuming you have a fast enough network.

[Arlo]

Originally posted by Alex Duffield:
<STRONG>Could you not just mount the server volume im OS9 and use Retrospect to back up the drive??? Assuming you have a fast enough network.</STRONG>

Hmm hadn't thought of that...I'll have to try it.

[utidjian]

Could you not just mount the server volume im OS9 and use Retrospect to back up the drive??? Assuming you have a fast enough network.

That may work for HFS/HFS+ volumes... but will it work for UFS volumes? Will it backup file permissions and soft links? Asssuming that it can do that... will it be able to restore them correctly?

I *know* that dump works to an IDE HDD for UFS and HFS/HFS+ volumes. I could not get rmt to work with an external Quantum DLT 2000.

-DU-...etc...

[Gee4orce]

tar ?

What's the accepted 'best practice' in the Unix world ? tar, dump, or something else ?

[muchfresh]

tar and dump wont preserve resource fork info.

[utidjian]

tar and dump will preserve resouce fork info but in a round-about way. AFAIK they don't grok HFS+. However, on my Linux servers that share files via netatalk to the Mac clients, ALL files are stored on ext2 partitions. tar, dump, cpio whatever backs them up perfectly (I prefer dump). When a Mac accesses the share from the Linux server it creates a .AppleDouble folder, which is invisible to the Mac, and stores all resourcefork data in there. It also creates a .AppleDesktop folder with all the desktop data. The Linux/Unix backup tools handle all this without any problem... all data from a partition gets backed up in a single session.

I really don't know how Apple is going to handle this in OS-X, if at all. Perhaps they will leave it to third party application writers to solve. Perhaps one will back up UFS volumes in one session and HFS+ volumes in another. In any case, it appears that OS-X can read and write to the HFS+ volumes I have. If it can read the resource fork metadata as some file then it should be able to restore that file.

My backup scheme on my Linux server is two tiered:

The /home volume where all user data is stored (also all web, a copy of databases, and a copy of /etc) is one huge RAID0 volume. Each night at 4:02AM (approx) all of this is mirrored to an identical RAID0 volume using a little utility called cpbk. A cron script controls this. A list of all files that have been mirrored is logged and is emailed to root. cpbk (after the initial run) only copies what has changed since the last run. It removes copies of files and folder that have been deleted from the original and so maintains a mirror of the original. This takes about 2 minutes on an average day. The disks are then unmounted.

Each morning I run a cron script that uses dump and it does a level 2 differential backup from the previous weeks level 1. Each month I do two level 0s of the entire system and take a copy offsite. The level 2s typically take about 10 minutes using DLT tapes. The level 0s take 8 hours! On weekends (when I run the level 1 dump) I just ssh to the server, start a screen session, start the dump, detatch the session and log off.

If a user "loses" a file I can just mount the backup disks and copy it over for them. If the original /home volume gets hosed it takes about 2 minutes (in a practice run) to umount the original and mount the backup as the original. Worst case: If the machine melts down, it will take 8+ hours to completely restore from archive tapes. At most my users will lose a days work.

Only improvement I want to make is to build a backup server... but I will still archive to tape. The advantage of a backup server is that one can keep a more current mirror of the users data and have a "quiet" machine when doing the dumps to tape. One can also bring it online more quickly than having to restore from tape... minutes compared to hours.