Re: Holding disk (feature request)

[Hauke Fath]

At 10:48 05.01.01 +1100, Michael Kennard wrote:
>Just a thought, when does it get time to copy to tape, this seems good in 
>theory but I guess it could only be efficient if you can run multiple 
>backup sessions in parallel.

Yep. The moment you interleave backups to holding disk and dumping 
(finished) backups from there to tape, you gain.

>I'm not sure about the problem with speed, I think tape drives can keep up 
>with network speeds though I can't tell you that for certain.

It's the other way 'round: High end tapes (DLT, AIT) are faster than the 
filesystem/network combo.

 hauke

--
Hauke FathTangro Software Components GmbH
 D-69115 Heidelberg
[EMAIL PROTECTED]   Ruf +49-6221-13336-0, Fax -21



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[Hauke Fath]

At 15:15 04.01.01 -0800, Seth D. Mattinen wrote:
>Add an option that does backups to a holding drive instead of directly to
>tape. When the holding drive is full or the backup of the client is complete
>(whichever comes first), transfer the holding drive backup set to a tape
>backup set. After all is done and on tape, clear the holding drive.

Yes, please! That is the one thing that puts Amanda in front of Retrospect 
(for the platforms it supports ;).

>1) Parallel backups of multiple clients. I don't see how one could do
>parallel backups to tape efficiently, but to a holding disk is a different
>story. Once it's done the holding disk gets transferred to tape and cleared
>off for the next round of backups.
>
>2) Increase speed of backups. Local hard drive to local tape drive is much
>faster than remote client direct to tape. The tape drive can then run at its
>maximum speed if everything is done locally. Also allows for more efficient
>use of tape.

On our R3 server (2x PPro 200, 768 MB RAM, RAID 1+5, DLT on separate 
controller), Retrospect is shoeshining the DLT when backing up the D drive 
with lots of little binaries and config files; I get ~20MB/min. A holding 
disk would be a real gain there.

>3) If Retrospect needs more tapes, backups can still proceed to the holding
>drive rather than be halted completely until more tapes are available.
>
>So, what does everyone think? Good idea or not?

Great idea. Though I am not sure they see the problem at Dantz: I had a 
Dantz representative tell me that RS would have no problem with keeping a 
DLT streaming over 10BaseT...

 hauke

--
Hauke FathTangro Software Components GmbH
 D-69115 Heidelberg
[EMAIL PROTECTED]   Ruf +49-6221-13336-0, Fax -21



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

RE: Holding disk (feature request)

[Nicholas Froome]

RE: Holding disk 


This is something that can be done now; just run one backup to the holding disk, then 
another from that to tape.

If this two-step process was managed by Retrospect (rather than being done with two 
scripts) it would still have to copy and verify on each pass so there probably 
wouldn't be much speed difference. 

I think the best way of doing it would be to run Backup Server overnight to backup 
clients, then run another Backup Server during the day to tape. That way you can 
juggle the server active times to optimise backup - and be around to swop tapes...


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

RE: Holding disk (feature request)

[Douglas B. McKay]

Perhaps the process could queue the files in 650MB (or whatever) size
chunks which could then be copied to tape as soon as the first one on
the disk is complete.  If the tape drive ran faster than the system
could fetch the data from the clients, you could simply increase the
number of backup processes writing to the holding area.

My tape drives can write data faster than I can get it from the
network if the files are small (in fact, I often see reduced tape
capacities because of all of the small files).  If they're large
files, tape speed is probably the bottleneck.  I have seen nearly
200MB/min on a switched 100MB connection with my drives (OnStream
ADR50).

I still think it would be great to be able to get the client machines
to do the catalog compares and snapshot creations in parallel and just
have the server fetch the data and write it to tape.

As for disk space concerns, I purchased a 40GB 7200 RPM Ultra 100
drive yesterday for $177.  I wouldn't use IDE drives for network
storage, but as a buffer, I think it would work fine.

   ...Doug

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf
Of matt barkdull
Sent: Thursday, January 04, 2001 5:36 PM
To: retro-talk
Subject: Re: Holding disk (feature request)


>Just a thought, when does it get time to copy to tape, this seems
>good in theory but I guess it could only be efficient if you can run
>multiple backup sessions in parallel. I'm not sure about the problem
>with speed, I think tape drives can keep up with network speeds
>though I can't tell you that for certain.
>
>I do like the idea of the hard drive taking over as a fail over,
>"the backup must go on".


This might work well for clients with small amounts of data, but just
imagine trying to keep more disk space than your clients on the
server.

Didn't we just go through a discussion on file sizes?  So if you do a
backup to file, there is a limitation of 2GB(?) of that file.  If
they break that barrier, then the rest of the stuff is fairly easy I
would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:<http://list.working-dogs.com/lists/retro-talk/>
Search:  <http://www.mail-archive.com/retro-talk%40latchkey.com/>

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[Rudy Richter]

AFAIK the 2GB file size limit for backup to file was fixed in the mac 4.3
version.
-- 
Rudy A Richter 
Goddard Space Flight Center
Earth Science Technology Office (ESTO)
Code 710 Server Admin

301-286-4429

> 
> Didn't we just go through a discussion on file sizes?  So if you do a
> backup to file, there is a limitation of 2GB(?) of that file.  If
> they break that barrier, then the rest of the stuff is fairly easy I
> would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[matt barkdull]

>Just a thought, when does it get time to copy to tape, this seems 
>good in theory but I guess it could only be efficient if you can run 
>multiple backup sessions in parallel. I'm not sure about the problem 
>with speed, I think tape drives can keep up with network speeds 
>though I can't tell you that for certain.
>
>I do like the idea of the hard drive taking over as a fail over, 
>"the backup must go on".


This might work well for clients with small amounts of data, but just 
imagine trying to keep more disk space than your clients on the 
server.

Didn't we just go through a discussion on file sizes?  So if you do a 
backup to file, there is a limitation of 2GB(?) of that file.  If 
they break that barrier, then the rest of the stuff is fairly easy I 
would think.



--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Re: Holding disk (feature request)

[Michael Kennard]

Just a thought, when does it get time to copy to tape, this seems 
good in theory but I guess it could only be efficient if you can run 
multiple backup sessions in parallel. I'm not sure about the problem 
with speed, I think tape drives can keep up with network speeds 
though I can't tell you that for certain.

I do like the idea of the hard drive taking over as a fail over, "the 
backup must go on".

Thanks for this idea. I did try something like this for Internet 
backups and put to tape till the files got corrupted and I had to 
scrap the whole idea.

Lets see what dantz thinks.

Michael

>Since it seems we're on the subject of feature requests, speeds of backups
>over network to tape and so on, here's what I'd like to see added to
>Retrospect. I'll be talking about tapes because that's what I use, but I'm
>sure this would apply to any sort of backup set.
>
>Add an option that does backups to a holding drive instead of directly to
>tape. When the holding drive is full or the backup of the client is complete
>(whichever comes first), transfer the holding drive backup set to a tape
>backup set. After all is done and on tape, clear the holding drive.
>
>This would be kind of like doing a set transfer from a file backup set to a
>tape backup set, but in an automated way. This would accomplish a few things
>from my perspective.
>
>1) Parallel backups of multiple clients. I don't see how one could do
>parallel backups to tape efficiently, but to a holding disk is a different
>story. Once it's done the holding disk gets transferred to tape and cleared
>off for the next round of backups.
>
>2) Increase speed of backups. Local hard drive to local tape drive is much
>faster than remote client direct to tape. The tape drive can then run at its
>maximum speed if everything is done locally. Also allows for more efficient
>use of tape.
>
>3) If Retrospect needs more tapes, backups can still proceed to the holding
>drive rather than be halted completely until more tapes are available.
>
>So, what does everyone think? Good idea or not?
>
>--
>Seth D. Mattinen  [EMAIL PROTECTED]  http://roller.reno.nv.us/
>PGP Key: http://seth.mattinen.org/pgp.php
>Tomorrow holds such better days. Days when I can still feel alive.


--
--
To subscribe:[EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:
Search:  

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.