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
> > 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
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
> In anycase my script needs work. Thanks a lot for the feedback you
> gave me a lot of ideas.