Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISO Creation after the backup archive ? #264

Closed
Florent38 opened this issue Jun 28, 2013 · 15 comments
Closed

ISO Creation after the backup archive ? #264

Florent38 opened this issue Jun 28, 2013 · 15 comments
Labels
enhancement Adaptions and new features

Comments

@Florent38
Copy link
Contributor

Hi,

I'm investigating DVD backup and I think rear architecture is not suitable for this because the backup archive are made after the ISO. Why not switch the workflow like this :

SourceStage "prep"
SourceStage "layout/save"
SourceStage "rescue"
SourceStage "build"
SourceStage "pack"
SourceStage "backup"
SourceStage "output"

instead of :

SourceStage "prep"
SourceStage "layout/save"
SourceStage "rescue"
SourceStage "build"
SourceStage "pack"
SourceStage "output"
SourceStage "backup"

@jhoekx
Copy link
Contributor

jhoekx commented Jun 28, 2013

This is necessary because of the OBDR workflow.

You could add a check for that workflow and keep the current stage ordering for that one. I believe there are quite a few scripts that depend on the order (but maybe not :-).

@dagwieers
Copy link
Contributor

The OBDR workflow (One-Button-Disaster-Recovery) is a tape-based recovery image solution. The tape drive emulates a bootable CDROM device and with a properly devised tape (which consists of an ISO image, followed by a tar backup) one can restore the complete system with a single tape using a single-button procedure to make the system boot from this tape.

That is why we need the ISO on disk (and on tape) before we can write the backup to tape !

@jhoekx
Copy link
Contributor

jhoekx commented Jun 29, 2013

Just some more thoughts about DVDs with backup on them since I'm not convinced that moving the stages is necessary: If you want a complete backup on DVD, you need to create the backup and need space for that. Then you need to create the iso, so you need 3 times the space.

A good solution (and the one used by MondoRescue) is to create a small iso image with the rescue system and then create multiple smaller sized images. That does not need changing the order.

@dagwieers
Copy link
Contributor

@jhoekx I think it is possible to add pathspec (see manual) to the command line where you basically say this directory in my ISO image should be that directory on disk located here. IIRC this avoids the second copy.

@Florent38
Copy link
Contributor Author

I don't know pathspec option but sounds interesting.
IMO a small ISO with the rescue system and multiple ISO for the backup is not a good solution (too many CD/DVD).

There is 3 options :

  1. minimal ISO + multiple ISO for the backup
  2. Change the stage order (only for ISO and DVD output) and create one or multiple ISO
  3. create minimal ISO and the backup archive, then extract the ISO and create one or multiple ISO with the bakcup archive. With this solution, we don't change the stage order and we can add an option like BACKUP_IN_ISO.

What do you think about this ?

@dagwieers
Copy link
Contributor

@Florent38 I think option 2 makes the most sense. By default, create the ISO and then make the backup, except if the backup is needed inside the ISO. In this case make it part of the creation of the ISO. The downside of making it part of the ISO as-is, is that it is not compressed, the advantage of this is that the files are accessible without effort.

BTW pathspec is not an option, these are the arguments to mkisofs; e.g.

genisoimage [options] [-o filename] backup/etc=/etc backup/usr=/usr backup/var=/var

@schlomo
Copy link
Member

schlomo commented Jul 1, 2013

I would like to better understand the backup-on-DVD scenario: Do we talk
about creating an ISO image or do we talk about writing to a DVD writer? In
the latter case I could imagine using multi-session to solve the problem:
1st session contains the boot ISO and 2nd session the backup data. While
booting only the 1st session is seen but later when mounting only the 2nd
session counts.

BTW, do we already create Hybrid ISOs which can be dd'ed onto a USB drive?

Another thought: Most modern DVD writers also handle DVD-RAM which can be
used as a block device and which might work with the backup-to-USB code...

On 1 July 2013 12:28, Dag Wieers notifications@github.com wrote:

@Florent38 https://github.com/Florent38 I think option 2 makes the most
sense. By default, create the ISO and then make the backup, except if the
backup is needed inside the ISO. In this case make it part of the creation
of the ISO. The downside of making it part of the ISO as-is, is that it is
not compressed, the advantage of this is that the files are accessible
without effort.

BTW pathspec is not an option, these are the arguments to mkisofs; e.g.

genisoimage [options] [-o filename] backup/etc=/etc backup/usr=/usr backup/var=/var


Reply to this email directly or view it on GitHubhttps://github.com//issues/264#issuecomment-20273965
.

@Florent38
Copy link
Contributor Author

@dagwieers I'm agree with you for the option 2 but after the message of @schlomo, i think we can do better ;)

@schlomo We talk about writing to a CD/DVD. IMO, the use of multi-session CD/DVD is a good solution to solve the problem, we don't have to change the stage order just burn the first ISO, and create/burn next ISOs (and split the backup if necessary)

@schlomo
Copy link
Member

schlomo commented Jul 2, 2013

@Florent38 thanks. I would find that a cool way, though I would advice some tests with your hardware. What I wrote is based on tests I did some 10 years ago...

Do you think that the OUTPUT=ISO should also support writing to a device instead of an ISO image? Or should we create a new OUTPUT=DVD that maybe includes some stuff from OUTPUT=ISO?

@schlomo
Copy link
Member

schlomo commented Jul 2, 2013

What I mean is that I could imagine that the use case "backup data on disc" would be only supported when writing to the disc directly and not to an ISO image... (Though I don't know if one could test that in a VM)

@schlomo
Copy link
Member

schlomo commented Jul 2, 2013

https://www.virtualbox.org/ticket/3266 was the only thing I could find in a quick search. IIRC there are some virtual DVD recorder solutions for Windows...

@Florent38
Copy link
Contributor Author

We should create a new output (like OUTPUT=DVD) to be more consistent with other ReaR output like USB.
I can test multi-session CD/DVD on physical server.

@Florent38
Copy link
Contributor Author

After a meeting with our manager, it was decided that only the backup into the ISO is needed. The user have to burn ISO himself. So i think an option like BACKUP_IN_ISO is a good way to implement this.

Algo :

SourceStage "prep"
SourceStage "layout/save"
SourceStage "rescue"
SourceStage "build"
SourceStage "pack"
if [[ "$OUTPUT" = "ISO" && "BACKUP_IN_ISO" =~ ^[yY1] ]]; then 
    SourceStage "backup"
    SourceStage "output"
else
    SourceStage "output"
    SourceStage "backup"
fi

What do you think about this ?

@schlomo
Copy link
Member

schlomo commented Jul 3, 2013

Why not try to append the backup file(s) with growisofs -M rear.iso <further genisoimage options> (Assuming that multisession booting works)? That way we could keep the stage order and now bother with script dependency troubles.

Sadly the genisoimage -stream-media-size and -stream-file-name options don't work with multisession, otherwise this would be even simpler and cooler. And this also does not allow to add more files next to the tar archive...

@dagwieers
Copy link
Contributor

@Florent38 What I would do is use something like BACKUP_URL="iso://path/to/backup" rather than have a new variable BACKUP_IN_ISO. The reason is that introducing new options that might be mutual exclusive with other options is hard to overcome and can lead to strange bugreports. Whereas BACKUP_URL can only be set once.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adaptions and new features
Projects
None yet
Development

No branches or pull requests

4 participants