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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]