<div dir="ltr">On Wed, Oct 28, 2015 at 2:19 AM, Alex Carver <span dir="ltr"><<a href="mailto:agcarver+ale@acarver.net" target="_blank">agcarver+ale@acarver.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 2015-10-27 19:51, Steve Litt wrote:<br>
> On Tue, 27 Oct 2015 08:02:39 -0700<br>
> Alex Carver <<a href="mailto:agcarver%2Bale@acarver.net">agcarver+ale@acarver.net</a>> wrote:<br>
><br>
>> Ok, Google is failing me today. I've got some large files (larger<br>
>> than 5GB each) that I need to archive to DVD so I'll have to span<br>
>> DVDs. The problem is I can't seem to find the appropriate magic<br>
>> incantations to accomplish this.<br>
><br>
> You've gotten a bunch of great answers to the question of how to split<br>
> files. Another aspect is how to pack them onto DVDs. For instance, that<br>
> last file of each split will be smaller than the DVD capacity, and if<br>
> you have some files that are naturally smaller than the DVD capacity,<br>
> you need to pack them too.<br>
><br>
> I once wrote a Ruby program to perform a backtracking algorithm to find<br>
> the very tightest way to pack files. That's the tightest alternative,<br>
> but years later, I found myself loathe to modify that program (when Ruby<br>
> changed versions) because it was so complicated. A slightly less<br>
> efficient, but *much* simpler algorithm is to keep on writing the<br>
> biggest file that will fit in the remaining space. This is especially<br>
> good if you have lots of files of widely varying space.<br>
<br>
</span>Packing efficiency doesn't matter to me in general for backups (I care<br>
more about having the copy even if it takes extra media) but I also<br>
can't do anything unusual in this case because it's a work backup.<br>
Archival data has to be recoverable in the future so there's a limited<br>
set of tools that I am permitted to use to generate the archive in the<br>
first place. So I could tar all the files into one big lump, split them<br>
with split into 4 GB chunks and burn all of those chunks (plus the small<br>
chunk that was left over at the end) onto however many DVDs it takes.<br>
That's what I did because tar and split (and later, cat for merging) are<br>
standard and accepted. None of the final files on the DVDs are unusual<br>
(other than the DVDs having a single file with the split names of xaa,<br>
xab, etc.) and I only have to include a small text file to describe the<br>
file and the recovery method.<br>
<br>
So that's exactly what I did in this case because I had six files to<br>
archive that were over 3GB each (an 18, a 13, a 7, a 4, and a couple 3's<br>
and all of these were actually single-file backups from a specific<br>
backup program). It worked well, I burned four DVDs with no issues.<br>
Three were full and the last was about 25% full but that's ok.<br>
<span class=""><br>
><br>
>><br>
>> The file image and burning tools tools available are genisoimage and<br>
>> wodim (unfortunately no mkisofs or cdrecord, thanks Debian).<br>
><br>
> Wodim is just the new name for cdrecord.<br>
><br>
> I wasn't aware Debian didn't offer mkisofs. I used Wheezy til I<br>
> dumpstered it in favor of Void two weeks ago, and I *know* it had<br>
> growisofs, because I used growisofs every time I did a Blu-ray backup.<br>
><br>
<br>
</span>I know wodim is cdrecord except it's not, there's some bugs in wodim<br>
that aren't present in cdrecord.<br>
<br>
As for mkisofs, yes Debian pulled the wodim stunt and created<br>
genisoimage to replace mkisofs. Growisofs is actually a symlink/script<br>
that calls genisoimage.<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br></div><div class="gmail_extra">For archival purposes, be aware that DVDs, especially burned ones, degrade pretty quickly over time. I'd probably make a duplicate of each disc. Also, you might consider creating parchive[1] recovery sets of all the files, so if there are partial problems when reading them back, you can hopefully recover that data from the parchive set. There is a CentOS rpm for that somewhere.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In the future, instead of breaking down the files into large chunks, break them down into smaller ones (like 250MB), and then you can pack them onto the disc as needed. Also, the split command allows you to set a prefix, which is really a better way to name files than accepting the default 'xaa' format. Something like:<br></div><div class="gmail_extra"> split --bytes=250M datafile datafile-split.<br></div><div class="gmail_extra">will result in files named like "datafile-split.aa", "datafile-split.ab", etc...<br><br></div><div class="gmail_extra">[1] <a href="https://github.com/Parchive/par2cmdline">https://github.com/Parchive/par2cmdline</a><br><br clear="all"><div>~ Brian Mathis<br></div>@orev<br><br></div></div>