[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Have DVD burner, will backup!



On Saturday 17 June 2006 01:16, Daniel Johnson wrote:
> > Trying it out now with a noburn option with a .dar file size limit. See
> > if this works. Am I correct to assume that it will fill the first one,
> > burn it while filling the next one, remove it after burning/verifying and
> > continue until done/disk is full?
>
> I had never thought of burning the DVD multisession in order to reduce
> temporary storage.  I was using the file size limit because mkisofs
> refuses to add any file larger than 2 gigs to an ISO so I needed the
> option in order to get it to fill a whole dvd at all.

The other script (darmonizer) defaults its size to the full 4 gigs.

>
> > Still takes a very long time and verifying will also take a long time.
> > This ammount of time, if user intervention be required, will discourage
> > backups.
>
> Yeah.  The real time savings is in incremental backups where it only
> backs up the stuff that hasn't been backed up before, and changes.  I
> haven't taken that ability from dar, and put it in my script yet.
>
> > So sometime along the line, needed:
> > 1. Tell me how many disks I will need and some time estimates.
>
> When compression is being used it is impossible to know ahead of time
> exactly how much space it will take.  Time is dependent on not only
> disk IO speed, but how long it takes to compress data.  Really
> anything I come up with would be an estimate, and I'm not sure how to
> come up with a good number yet.  Maybe collecting statistics will help
> set good estimation defaults.
>
Estimate is good enough. Any reasonable estimate. If it says 8 hours, then 
start it and go to sleep. Of course, no guarantee that the thing will still 
be up 8 hours later but this is Linux. Windows would definitely crash out 
before then.

> > 2. Option not to verity. The other script has this.
>
> Unverified backups should not be trusted, but I guess I can add this
> if it makes people happy.

I agree, but folks wont backup in these time frames.

> > 3. Exclude options. I think dar defaults these.
>
> There are a whole bunch of options hard coded into the script to not
> compress filetypes that are already compressed.  Is this what you
> mean?

I mean stay off certain directories, such as /mnt, /tmp, etc. There are a lot 
of hidden directorys which I may want to exclude such as those that cache 
browsers and such, but others have kde options and I might want to keep in a 
backup. This is all volumunous stuff!


> > Anyway, the slice size limit did not work. Should--simply passed on to
> > dar?
>
> significant amounts of code would have to be rewritten I think.

The size limit in darmizer, simply passed on, did work. What did not work was 
keeping the thing going after the first slice was burnt. They enfouce a time 
stamp making it difficult to reuse that disk (I hard coded it but was not 
successful is rewrting the script to keep it running until all slices are 
burnt).
> In anycase my script needs work.  Thanks a lot for the feedback you
> gave me a lot of ideas.



Reply to: