Re: Questions about dump/restore to/from DVD media
In message 20121105051447.6eef32ef.free...@edvax.de, Polytropon free...@edvax.de wrote: The problem is that delegating compression to a sub-task would imply that dump cannot precisely adjust its output to match the media size (as the limit is now defined by how good the compression works). Correct. We have both just said the exact same thing in different ways. In order to have _compression_ of the dump data _and_ still be able to divide the (post-compression) data into nice proper 2KB chunks (as required for DVD+/-R writing) the compression step itself would need to be integrated into the dump program itself (and then, for symmetry, if for no other reason, into restore as well). Chunk size _and_ media size matter (as dump would have to know when the media is expected to be nearly-full _with_ compression) Correct. We are both still just violently agreeing. Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
On Sun, 04 Nov 2012 16:56:58 -0800, Ronald F. Guilmette wrote: I would like to make a backup of one of my systems using dump(8) in order to be sure that I get everything, including all of the obscure file attribute bits. That eliminates at least some tools. I have been using a similar idea in the past to make a backup of a system using multiple CD-Rs and I think cpio or pax, but only for data files that do not come with the whole range of special attributes. Oh wait, it was afio, on FreeBSD 4... I would like to make this backup to a _minimal_ number of DVD+R disks. If you think you can add compression to your files (if it makes sense), it should be incorporated to the command. What's the proper procedure for this? In the dump(8) man page, I see the following example: /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u There are several problems with this example, as far as I am concerned. First I have no particular interest in, or need for _either_ an ISO 9660 _or_ a UDF file system on my backup media. And in fact, that seems to me as if it is likely to be an utter waste of (precious) space on the backup media. Can't I just put the output of the dump command _directly_ onto the output DVD+R media? I think this command exactly does this. Your idea is correct: There is no need for ISO-9660 or UDF on backup media as it will not be mounted, but processed with the proper restore tool. The command growisofs -Z /dev/cd0=file will record the file like an image to the media. In most cases, that would be an ISO-9660 file system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered file stuff.iso). In _this_ case, the input data is read directly from file descriptor 0, stdin. Whatever appears there, it will be written to the media. Here it is dump's output data stream. If so, how would I do this? Would a command such as the following work? /sbin/dump -0u -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u If not, why not? As far as I know, direct device access for writing does not work here. There are some operating systems that support an approach like this (IRIX for example, if I remember correctly), but FreeBSD doesn't. Depending on your OS version, acd0 != cd0 might appear, being different in access method, i. e. ATAPI vs. ATAPICAM (SCSI over ATA). Actually, I just noticed in the dump manpage the -f option. So would this work in place of the above command line? /sbin/dump -0u -L -C16 -B4589840 -f /dev/acd0 /u And if THAT works, then can dump properly sense the actual end-of-media on /dev/acd0, so that the -B option can just be ommitted? I've never tried if /dev/acd0 (or /dev/cd0 for the reason mentioned above) would be able to start a writing session by receiving data in that kind of way. The -f option is typically used to send data to files, or to - to hand them to another program or pipeline. It seems that doing so for devices (and causing the _physical_ devices to do something with it) is not possible. Another issue is that I most definitely want to use an absolute minimum of DVD+Rs to store the dump. So I am wondering how I might be able to wedge gzip into this whole process. Could I do something like this? If not, why not? /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u Taking the initial approach of /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u it could be something like this: /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u Not tested, just an idea. Just check how -P interacts with /dev/fd/0 and - for stdin _within_ the pipe command. Lastly, I want to make a backup of one entire _system_... not just one of the several partitions that compose that system. How exactly can I do this? At least not with dump. The dump utility operates on file systems, this means it takes partitions as input. Whatever is _one_ partition can be processed per step. Maybe you could concatenate runs of dump of all the present partitions; however it will be a bit more complicated to restore them using the restore program, which reads file system dumps and outputs the data to initialized and mounted file systems. I mean sure, I can back up each partition separately, using dump, one at a time, but if I do that then the logical implication would seem to be that on the last DVD+R used to make a backup of each of the partitions, there could possibly be a lot of unused/wasted space which could have been used to store the first part of the dump for the next partition in turn. Yes, that is quite possible. In this case, using dd would maybe be better. You would use it to copy the whole disk containing all the partitions, add gzip, break it into multi-volume parts and then record it to DVD+R. Is there any way to effectively deal with _this_ issue? Not per se, but I think all the required parts are in the system, it's just the
Re: Questions about dump/restore to/from DVD media
On Sun, Nov 4, 2012 at 4:56 PM, Ronald F. Guilmette r...@tristatelogic.comwrote: I would like to make a backup of one of my systems using dump(8) in order to be sure that I get everything, including all of the obscure file attribute bits. I would like to make this backup to a _minimal_ number of DVD+R disks. What's the proper procedure for this? In the dump(8) man page, I see the following example: /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u There are several problems with this example, as far as I am concerned. First I have no particular interest in, or need for _either_ an ISO 9660 _or_ a UDF file system on my backup media. And in fact, that seems to me as if it is likely to be an utter waste of (precious) space on the backup media. Can't I just put the output of the dump command _directly_ onto the output DVD+R media? If so, how would I do this? Would a command such as the following work? /sbin/dump -0u -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u If not, why not? (I already know for sure that I can _read_ everything off of a DVD+R using just dd, so it seems logical that I should likewise be able to write an entire CD using just dd, but I suspect that there may be more to it that this, since I've never seen any references or examples anywhere of anybody writing either CDs or DVDs using dd.) Actually, I just noticed in the dump manpage the -f option. So would this work in place of the above command line? /sbin/dump -0u -L -C16 -B4589840 -f /dev/acd0 /u And if THAT works, then can dump properly sense the actual end-of-media on /dev/acd0, so that the -B option can just be ommitted? Another issue is that I most definitely want to use an absolute minimum of DVD+Rs to store the dump. So I am wondering how I might be able to wedge gzip into this whole process. Could I do something like this? If not, why not? /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u Lastly, I want to make a backup of one entire _system_... not just one of the several partitions that compose that system. How exactly can I do this? I mean sure, I can back up each partition separately, using dump, one at a time, but if I do that then the logical implication would seem to be that on the last DVD+R used to make a backup of each of the partitions, there could possibly be a lot of unused/wasted space which could have been used to store the first part of the dump for the next partition in turn. Is there any way to effectively deal with _this_ issue? Regards, rfg Assume one file will NOT be copied more than ONE DVD , i.e. , each file will be completely recorded on one DVD : http://en.wikipedia.org/wiki/Cutting_stock_problem Thank you very much . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
On 11/05/12 11:18, Polytropon wrote: On Sun, 04 Nov 2012 16:56:58 -0800, Ronald F. Guilmette wrote: I would like to make a backup of one of my systems using dump(8) in order to be sure that I get everything, including all of the obscure file attribute bits. That eliminates at least some tools. I have been using a similar idea in the past to make a backup of a system using multiple CD-Rs and I think cpio or pax, but only for data files that do not come with the whole range of special attributes. Oh wait, it was afio, on FreeBSD 4... I would like to make this backup to a _minimal_ number of DVD+R disks. If you think you can add compression to your files (if it makes sense), it should be incorporated to the command. What's the proper procedure for this? In the dump(8) man page, I see the following example: /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u There are several problems with this example, as far as I am concerned. First I have no particular interest in, or need for _either_ an ISO 9660 _or_ a UDF file system on my backup media. And in fact, that seems to me as if it is likely to be an utter waste of (precious) space on the backup media. Can't I just put the output of the dump command _directly_ onto the output DVD+R media? I think this command exactly does this. Your idea is correct: There is no need for ISO-9660 or UDF on backup media as it will not be mounted, but processed with the proper restore tool. The command growisofs -Z /dev/cd0=file will record the file like an image to the media. In most cases, that would be an ISO-9660 file system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered file stuff.iso). In _this_ case, the input data is read directly from file descriptor 0, stdin. Whatever appears there, it will be written to the media. Here it is dump's output data stream. If so, how would I do this? Would a command such as the following work? /sbin/dump -0u -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u If not, why not? As far as I know, direct device access for writing does not work here. There are some operating systems that support an approach like this (IRIX for example, if I remember correctly), but FreeBSD doesn't. Depending on your OS version, acd0 != cd0 might appear, being different in access method, i. e. ATAPI vs. ATAPICAM (SCSI over ATA). Actually, I just noticed in the dump manpage the -f option. So would this work in place of the above command line? /sbin/dump -0u -L -C16 -B4589840 -f /dev/acd0 /u And if THAT works, then can dump properly sense the actual end-of-media on /dev/acd0, so that the -B option can just be ommitted? I've never tried if /dev/acd0 (or /dev/cd0 for the reason mentioned above) would be able to start a writing session by receiving data in that kind of way. The -f option is typically used to send data to files, or to - to hand them to another program or pipeline. It seems that doing so for devices (and causing the _physical_ devices to do something with it) is not possible. Another issue is that I most definitely want to use an absolute minimum of DVD+Rs to store the dump. So I am wondering how I might be able to wedge gzip into this whole process. Could I do something like this? If not, why not? /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | dd of=/dev/acd0 bs=2048' /u Taking the initial approach of /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u it could be something like this: /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u Not tested, just an idea. Just check how -P interacts with /dev/fd/0 and - for stdin _within_ the pipe command. Lastly, I want to make a backup of one entire _system_... not just one of the several partitions that compose that system. How exactly can I do this? At least not with dump. The dump utility operates on file systems, this means it takes partitions as input. Whatever is _one_ partition can be processed per step. Maybe you could concatenate runs of dump of all the present partitions; however it will be a bit more complicated to restore them using the restore program, which reads file system dumps and outputs the data to initialized and mounted file systems. I mean sure, I can back up each partition separately, using dump, one at a time, but if I do that then the logical implication would seem to be that on the last DVD+R used to make a backup of each of the partitions, there could possibly be a lot of unused/wasted space which could have been used to store the first part of the dump for the next partition in turn. Yes, that is quite possible. In this case, using dd would maybe be better. You would use it to copy the whole disk containing all the partitions, add gzip, break it into multi-volume parts and then record it to DVD+R. Is there any way to effectively deal with _this_ issue? Not per se, but I
Re: Questions about dump/restore to/from DVD media
In message caogwamvoncti7akmtjw0+caastfhfae5gw+pkmh+4ldr00-...@mail.gmail.com Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Assume one file will NOT be copied more than ONE DVD , i.e. , each file will be completely recorded on one DVD : http://en.wikipedia.org/wiki/Cutting_stock_problem The problem you cited is an interesting one, but I do not believe that it is at all relevant to the current discussion for the simple reason that this cutting problem is based on the assmption that one thing (e.g. a cut piece of paper) cannot be spread across two or more of the available units of raw material (e.g. a standard roll of paper). I'm sure that is true for paper, but as regards to FreeBSD partition backups, these have always been allowed to cross output volume boundaries, I think, e.g. spilling off the end of one backup tape and onto the beginning of the next backup tape. Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
In message 20121105021817.fc5bff1b.free...@edvax.de, Polytropon free...@edvax.de wrote: I would like to make this backup to a _minimal_ number of DVD+R disks. If you think you can add compression to your files (if it makes sense), it should be incorporated to the command. Yes. There really ought to be a -z option integrated into both dump and restore commands. The command growisofs -Z /dev/cd0=file will record the file like an image to the media. In most cases, that would be an ISO-9660 file system, like growisofs -Z /dev/cd0=stuff.iso (with a premastered file stuff.iso). In _this_ case, the input data is read directly from file descriptor 0, stdin. Whatever appears there, it will be written to the media. Ah! OK. I see now. Thank you. If so, how would I do this? Would a command such as the following work? /sbin/dump -0u -L -C16 -B4589840 -P 'dd of=/dev/acd0 bs=2048' /u If not, why not? As far as I know, direct device access for writing does not work here. Yes, apparently not. Bit I _did_ just find something rather interesting in this context. Look at this: http://sg.danny.cz/sg/ddpt.html I have no idea why it isn't already in the ports tree. I'll probably try it out and see if it works. Another issue is that I most definitely want to use an absolute minimum... Taking the initial approach of /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u it could be something like this: /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u Yes. I see. That makes sense. But as I said (above) to make this really work right, dump restore really need to have -z options, and do the zipping/unzipping internally. Only if this were available could dump properly deal with end-of-media on any given output volume, I think. Lastly, I want to make a backup of one entire _system_... not just one of the several partitions that compose that system. How exactly can I do this? At least not with dump. The dump utility operates on file systems, this means it takes partitions as input. Whatever is _one_ partition can be processed per step. Well, this is entirely sub-optimal. (I hate to say it, because in general I loath despise Windows, but even Windows has a built-in facility for making a single backup of an _entire_ system, and in a single step, *and*, I presume in a space-efficient manner.) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
On Sun, 04 Nov 2012 18:37:43 -0800, Ronald F. Guilmette wrote: In message 20121105021817.fc5bff1b.free...@edvax.de, Polytropon free...@edvax.de wrote: I would like to make this backup to a _minimal_ number of DVD+R disks. If you think you can add compression to your files (if it makes sense), it should be incorporated to the command. Yes. There really ought to be a -z option integrated into both dump and restore commands. Depending on _what_ kind of compression (gzip, bzip2, 7zip, xz etc.) there might be many of them. If utilizing the capabilities of libarchive is possible, it would be a nice option. Another issue is that I most definitely want to use an absolute minimum... Taking the initial approach of /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u it could be something like this: /sbin/dump -0u -L -C16 -B4589840 -P 'gzip | growisofs -Z /dev/cd0=-' /u Yes. I see. That makes sense. But as I said (above) to make this really work right, dump restore really need to have -z options, and do the zipping/unzipping internally. Only if this were available could dump properly deal with end-of-media on any given output volume, I think. The problem is that delegating compression to a sub-task would imply that dump cannot precisely adjust its output to match the media size (as the limit is now defined by how good the compression works). Instead an additional step would be required to make sure that a new media for the _compressed_ data stream is requested when it exceeds a certain limit. Additionally restore would have to use a comparable method of chaining the multiple volumes, as it requires operator attention and action. Lastly, I want to make a backup of one entire _system_... not just one of the several partitions that compose that system. How exactly can I do this? At least not with dump. The dump utility operates on file systems, this means it takes partitions as input. Whatever is _one_ partition can be processed per step. Well, this is entirely sub-optimal. It depends on how you did layout your system. Using dump + restore means to operate on partitions. Make the system one partition - deal with one partition. Make many partitions - need to deal with them individually. (I hate to say it, because in general I loath despise Windows, but even Windows has a built-in facility for making a single backup of an _entire_ system, and in a single step, *and*, I presume in a space-efficient manner.) That would be a task for dd. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
In message 50971b88.40...@herveybayaustralia.com.au, Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: Also, you may have considered this already (or not :) ), but you are using a direct write to backup your system, and then considering compression on top of that. CD/DVD filesystems incorporate some parity to allow for defects and scratches, so growisofs might be best to use to ensure some integrity to your data. Minimising your space may be good, but a single bit could render all your efforts for nought- especially given the compression leaves no room for error ;) I'm not sure if the error detection/correction on DVDs... either -Rs or +Rs... is a function of the _filesystem_. In fact I don't believe that it is, but I could be wrong. Google for this: DVD+R error correction and there are plenty of references. The ones that I read in the past seemed to suggest that the error detection/correction is a fundamental aspect of how data gets written to both -R and +R disks, totally independent of whether the data being written was organized into any type of filesystem or none at all. In fact, part of the reason that I only use DVD+Rs these days is because I read something that said that something like 1/4 of every block of data on DVD-R disks is not even covered by any error correction code AT ALL. Ah, yes... here is one such reference: http://adterrasperaspera.com/blog/2006/10/30/how-to-choose-cddvd-archival-media The DVD-R specification states that for every 192 bits, 64 of them are not protected under any scheme, 24 of them are protected by 24 bits of parity, and the last 56 bits are protected by another 24 bits of parity. This weird (to put it mildly) scheme allows you to easily scramble or lose 25% of the data that is required to read your disk! This information is almost more important than the actual data burned on the disc itself. The DVD+R specification, however, states that for every 204 bits of information, it is split into four blocks of 52 bits containing 1 sync bit to prevent misreading because of phase changes, 31 bits of data, and a 20 bit parity (that protects all 32 bits of data)... Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
In message 20121105035233.e3c4ae8a.free...@edvax.de, Polytropon free...@edvax.de wrote: But as I said (above) to make this really work right, dump restore really need to have -z options, and do the zipping/unzipping internally. Only if this were available could dump properly deal with end-of-media on any given output volume, I think. The problem is that delegating compression to a sub-task would imply that dump cannot precisely adjust its output to match the media size (as the limit is now defined by how good the compression works). Correct. We have both just said the exact same thing in different ways. In order to have _compression_ of the dump data _and_ still be able to divide the (post-compression) data into nice proper 2KB chunks (as required for DVD+/-R writing) the compression step itself would need to be integrated into the dump program itself (and then, for symmetry, if for no other reason, into restore as well). Using dump + restore means to operate on partitions. Make the system one partition - deal with one partition. Make many partitions - need to deal with them individually. Good point. (I hate to say it, because in general I loath despise Windows, but even Windows has a built-in facility for making a single backup of an _entire_ system, and in a single step, *and*, I presume in a space-efficient manner.) That would be a task for dd. :-) Sorry? I am not following you. How could dd ever substitute for the intelligence of dump(8), and specifically how could it avoid copying of blocks that are ``in'' the filesystem but which are not currently _allocated_ by the filesystem? (I am also not persuaded the dd could handle multiple partitions any better that dump(8) currently does... which is to say not at all, really.) Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote: In message 20121105035233.e3c4ae8a.free...@edvax.de, Polytropon free...@edvax.de wrote: But as I said (above) to make this really work right, dump restore really need to have -z options, and do the zipping/unzipping internally. Only if this were available could dump properly deal with end-of-media on any given output volume, I think. The problem is that delegating compression to a sub-task would imply that dump cannot precisely adjust its output to match the media size (as the limit is now defined by how good the compression works). Correct. We have both just said the exact same thing in different ways. In order to have _compression_ of the dump data _and_ still be able to divide the (post-compression) data into nice proper 2KB chunks (as required for DVD+/-R writing) the compression step itself would need to be integrated into the dump program itself (and then, for symmetry, if for no other reason, into restore as well). Chunk size _and_ media size matter (as dump would have to know when the media is expected to be nearly-full _with_ compression) because the operator will be required to deal with multi-volume media (next DVD). (I hate to say it, because in general I loath despise Windows, but even Windows has a built-in facility for making a single backup of an _entire_ system, and in a single step, *and*, I presume in a space-efficient manner.) That would be a task for dd. :-) Sorry? I am not following you. How could dd ever substitute for the intelligence of dump(8), and specifically how could it avoid copying of blocks that are ``in'' the filesystem but which are not currently _allocated_ by the filesystem? It cannot. :-) With dd, you could copy a disk including all aspects of the present slices and partitions (including file attributes and partitioning data, even boot elements), but it would maybe require a subsequent read and compare step to make sure that everything went well. (I am also not persuaded the dd could handle multiple partitions any better that dump(8) currently does... which is to say not at all, really.) It can - depending on what device you're reading from. Examples: dd if=/dev/ad0s1a - the root partition dd if=/dev/ad0s1- the 1st slice dd if=/dev/ad0 - the whole disk However, dd is very much bare metal and cannot handle multiple volumes and compression natively. It would be neccessary to have all those functionalities scripted additionally. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
On 11/05/12 14:14, Polytropon wrote: On Sun, 04 Nov 2012 19:49:24 -0800, Ronald F. Guilmette wrote: In message 20121105035233.e3c4ae8a.free...@edvax.de, Polytropon free...@edvax.de wrote: But as I said (above) to make this really work right, dump restore really need to have -z options, and do the zipping/unzipping internally. Only if this were available could dump properly deal with end-of-media on any given output volume, I think. The problem is that delegating compression to a sub-task would imply that dump cannot precisely adjust its output to match the media size (as the limit is now defined by how good the compression works). Correct. We have both just said the exact same thing in different ways. In order to have _compression_ of the dump data _and_ still be able to divide the (post-compression) data into nice proper 2KB chunks (as required for DVD+/-R writing) the compression step itself would need to be integrated into the dump program itself (and then, for symmetry, if for no other reason, into restore as well). Chunk size _and_ media size matter (as dump would have to know when the media is expected to be nearly-full _with_ compression) because the operator will be required to deal with multi-volume media (next DVD). (I hate to say it, because in general I loath despise Windows, but even Windows has a built-in facility for making a single backup of an _entire_ system, and in a single step, *and*, I presume in a space-efficient manner.) That would be a task for dd. :-) Sorry? I am not following you. How could dd ever substitute for the intelligence of dump(8), and specifically how could it avoid copying of blocks that are ``in'' the filesystem but which are not currently _allocated_ by the filesystem? It cannot. :-) With dd, you could copy a disk including all aspects of the present slices and partitions (including file attributes and partitioning data, even boot elements), but it would maybe require a subsequent read and compare step to make sure that everything went well. (I am also not persuaded the dd could handle multiple partitions any better that dump(8) currently does... which is to say not at all, really.) It can - depending on what device you're reading from. Examples: dd if=/dev/ad0s1a - the root partition dd if=/dev/ad0s1- the 1st slice dd if=/dev/ad0 - the whole disk However, dd is very much bare metal and cannot handle multiple volumes and compression natively. It would be neccessary to have all those functionalities scripted additionally. For reference, if one did backup the whole slice/disk using dd and then compressed the data, would that effectively compress all those 'unallocated' nodes? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Questions about dump/restore to/from DVD media
Date: Mon, 05 Nov 2012 15:42:45 +1000 From: Da Rock freebsd-questi...@herveybayaustralia.com.au Subject: Re: Questions about dump/restore to/from DVD media On 11/05/12 14:14, Polytropon wrote: For reference, if one did backup the whole slice/disk using dd and then compressed the data, would that effectively compress all those 'unallocated' nodes? NO. The unallocated' blocks still have whatever data was in them. *IF* you copy /dev/zero to a new file, to fill the disk, then rm -that- file, the compression will be higher. 'How much' depends on how empty the disk is. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
