Restoreing Dump on FreeBSD headless server

Jerry McAllister jerrymc at msu.edu
Mon Jan 4 23:04:45 UTC 2010


On Mon, Jan 04, 2010 at 11:03:41PM +0100, bsd wrote:

> 
> Le 4 janv. 2010 à 22:36, Jerry McAllister a écrit :
> 
> > On Mon, Jan 04, 2010 at 08:42:33PM +0100, bsd wrote:
> > 
> >> 
> >> Le 4 janv. 2010 à 19:56, Jerry McAllister a écrit :
> >> 
> >>> On Mon, Jan 04, 2010 at 07:08:51PM +0100, bsd wrote:
> >>> 
> >>>> Hello folks, 
> >>>> 
> >>>> 
> >>>> I would like to know how to proceed in order to restore a dump from a 
> >>>> backup headless server (remotely using ssh). 
> >>> 
> >>>> How am I supposed to proceed, should I first install the server (a FreeBSD 
> >>>> Fresh install with spare partition) then restore the dump on an empty 
> >>>> partition ?  
> >>> 
> >>> Depends on what you have and what you want to restore.
> >>> Is the reason for the restore because the old disk went belly up?
> >>> Or did you just nuke some stuff accidently.   Is the restore the
> >>> boot disk or an extra work disk?   
> >> 
> >> Well, to tell you the truth: I am using a remote backup solution since 2.5 
> >> years and the provider has just told me that he would no longer support 
> >> my hardware so I need to rebuild a new server based on my previous config
> > 
> > I am not clear on what you mean by a 'remote backup solution' - do you
> > mean that you are using dump(8) but writing to some remote device or
> > do you mean you are using some '3rd party' backup software/hardware
> > that your provider/hoster is supplying?
> 
> I am using dump(8). 
> I have successfully created a backup of all major partition of my server which is now secured on a remote HD. 
> 
> > 
> > 
> >>> In the first case, yes you will need to create something on the disk - 
> >>> some sort of filesystem.   Probably that would mean using a fixit
> >>> image to boot and do an fdisk(8), bsdlabel(8) and newfs(8).   
> >> 
> > 
> >> Ok, I think the server I will install that on might use some sort of 
> >> virtual KVM that could allow me to do that
> > 
> > Well, that could be helpful.   It should give you a console type access
> > which is convenient in installation situations.   Does that 'KVM' 
> > supply the backup device too, or talk to it directly?
> 
> I haven't tried It so I don't know what functionnality It offers? 
> But I guess I might start a fresh install from that console? 
> 
> At which point should I do the restore(8) in the install process ? 


??  As soon as you get the disk ready - fdisk and make a bootable slice
bsdlabel and make your partitions, newfs the partitions, then restore
the dumps.   There really isn't anything else to do once the restores
have successfully been done.    Just pull out the fixit and boot
normally.



> 
> > 
> >>> It the second case, the filesystem[s] is[are] still intact and you
> >>> only need to do an 'interactive' restore of just the files you want.
> >>> IF you are doing an intereactive restore and if you have room, it may 
> >>> be easiest to copy the whole dump file over to some big space on the 
> >>> system and run the restore from that copy.  Then you can just ssh in 
> >>> and run it just as if it was setting beside you.
> >>> 
> >>> The same might not be true if you are replacing a destroyed disk 
> >>> because the restore will be a complete one and no file selecting
> >>> will be necessary.
> >>> 
> >>> If you cannot get physical contact with the machine, and the disk was
> >>> damaged and replaced, you may have to learn how to do a network boot 
> >>> and install.   I have never had to do that so am not a good one to guide 
> >>> that process.   
> >> 
> > 
> >> Well my idea was to rebuild the new server based on the dump I have 
> >> realised (in order to save me the time to do the reinstall). 
> >> But from what you are telling me It might not be so easy
> > 
> > I am not clear again just what you are meaning by 'based on the dump
> > I have realised'.   Do you mean that  you would keep the filesystem
> > structure you have already?   IS there a dump file/tape for each
> > filesystem in the old system?   
> 
> Dump is stored on a remote HD. 
> There is one dump file per partition (not for /tmp). 

Sounds right.    Then make those partitions and newfs them.
You need to make a /tmp, but of course, you don't need to dump
and restore it.   

Also, remember that when you run from fixit, the sile storage "disk" is
in memory.   It is / and /usr, etc.   So, you need to make temporary
mount points starting in the '/' file system for the new ones while
you are restoring to them.    Something like /newroot, /newusr, /newvar
and /newhome  or whatever.   Then mount the newly newfs-ed partitions
to those mount points, cd in to each and run the restore -r for it.


> 
> > 
> > If that is what you mean, good.   There is no harm in keeping the
> > old filesystem structure if it was working for you.   Take a look
> > at how much is used in each filesystem and think if you need to
> > change the size.  But, that is just a detail of sizing the partitions
> > and not a critical structure consideration.   If the new system has
> > larger disk, then you can make use of it just by making bigger 
> > partitions where they are needed.
> 
> Ok. 
> 
> > 
> > 
> >>> 
> >>> In either case of having to create slices, partitions and filesystems,
> >>> you do not have to do a complete system install.  You need to do just
> >>> enough building to have the filesystems created and mountable.
> >> 
> >> Yes but how should I partition that ? 
> >> 
> >> Should I re-create the 
> >> 
> >> /
> >> /var
> >> /usr
> >> /tmp
> >> 
> >> or 
> >> 
> >> / with minimal system
> >> 
> >> and re-create the mapping with nothing on slice. 
> > 
> > Create what you want it to be and go from there unless the old and
> > the new structure are incompatible in some way.   My usual set of
> > partitions/filesystems are:
> > 
> >  /
> >  swap
> >  /tmp
> >  /usr
> >  /var
> >  /home   or other convenient name such as /bighome
> >  /work   if there is a lot of extra space on the new disk and
> >          you don't want it clumped in with the rest for some reason.
> >          I usually put all the rest in that /bighome  filesystem.
> >          If I have an extra disk with lots of space, I make that /work
> > 
> > 
> > But, if your structure is working for you, stick with it.
> > 
> >> 
> >> 
> >>> The fixit
> >>> is just fine for that.   If you can get that going remotely, then
> >>> do the fdisk, bsdlabel and newfs-s from that and then restore from 
> >>> the dump to the new filesystems.  
> >> 
> >> Ok, that should be the good path
> >> 
> > 
> > Yes, unless you are changing the structure (not size, but organization
> > of the filesystems) just make the partitions and newfs them and resture
> > the dumps to them.    
> > 
> >> 
> >>> Forget about doing a real install.
> >>> 
> >>>> 
> >>>> Should the new empty partition be the exact same size as the dumped 
> >>>> partition ? 
> >>> 
> >>> It just has to be large enough to hold what you restore.
> >>> In fact, it is a good time to increase or adjust filesystem sizes if
> >>> you have more room on the replacement disk.
> >> 
> >> Good
> >> 
> > 
> > That is the advantage of using dump/restore for your backups.  It is
> > agnostic to the size of the partition as long as there is enough room
> > to hold things.    Something like dd(1) which is great for some things
> > forces you to stick with the exact sector complement and so isn't
> > really a good backup tool.
> > 
> > One thing to consider, if you are copying from an old machine
> > to a new one is to create the slice/partitions/filesystems and
> > then use rsync to move the files from the old machine to the
> > new one.   It is quite efficient if both machines are available
> > to be running at the same time.   But, if you have to work from a
> > backup file or tape somewhere, then that is not a good option.
> 
> Ok Thank you very much Jerry. 
> As both filesystem are going to be up and running at the same time, I 
> guess It will be quite easy to do this operation? 
> Even if I have to crash couple of system on the new machine, that shouldn't 
> be a problem -- after all It is by experimenting that we all progress! 

Best check and see if rsync is available on the fixit.   It is
normally a port so it might not be.    You could still get it there,
but it becomes more complicated to use rsync if it not on the fixit.
In that case, you have to go back to restoring the dumps.
But, if you have both systems up and running, that is not difficult
using rsh - just takes a while.   rsync is faster if it is available.
Basically, you run a restore, but read from the rsh from the other 
system.  It has been a few years since the last time I did this, but
it wasn't hard to figure out.    

////jerry     
   
    
    
    
    

> 
> I'll maybe do a follow-up on the thread if I have problem somewhere during 
> the operation (It shouldn't take place until one week)? 
> 
> 
> Thanks. 
> 
> > 
> > ////jerry
> > 
> > 
> > 
> >>> 
> >>>> 
> >>>> Is there a tool that could allow me to restore remotely ? 
> >>>> 
> >>> 
> >>> You can use rsh(1).   I have done that.    
> >>> Probably some specific ssh method too, but I am so old I haven't
> >>> done one with that new fangled secure ssh yet...
> >> 
> >> Ok. 
> >> 
> >> 
> >> Thanks. 
> >> 
> >>> 
> >>> ////jerry    
> >>> 
> >>> 
> >>>> 
> >>>> Any advice or howto will be (very) welcome. 
> >>>> 
> >>>> 
> >>>> Thanks. 
> >>>> 
> >>>> 
> >>>> P.S. Happy new BSD year !! 
> >>>> 
> >>>> 
> >>>> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> >>>> Gregober ---> PGP ID --> 0x1BA3C2FD
> >>>> bsd @at@ todoo.biz
> >>>> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> >>>> 
> >>>> P "Please consider your environmental responsibility before printing this e-mail"
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> freebsd-questions at freebsd.org mailing list
> >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >>>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> >>>> 
> >> 
> >> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> >> Gregober ---> PGP ID --> 0x1BA3C2FD
> >> bsd @at@ todoo.biz
> >> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> >> 
> >> P "Please consider your environmental responsibility before printing this e-mail"
> >> 
> >> 
> >> _______________________________________________
> >> freebsd-questions at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> >> 
> 
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> Gregober ---> PGP ID --> 0x1BA3C2FD
> bsd @at@ todoo.biz
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
> 
> P "Please consider your environmental responsibility before printing this e-mail"
> 
> 
> 


More information about the freebsd-questions mailing list