[CentOS] Being Green, Time to make the servers sleep!

Robert Heller heller at deepsoft.com
Thu Mar 19 13:54:09 UTC 2009


At Thu, 19 Mar 2009 14:07:33 +0100 CentOS mailing list <centos at centos.org> wrote:

> 
> Robert Heller wrote:
> > At Thu, 19 Mar 2009 12:54:41 +0100 CentOS mailing list <centos at centos.org> wrote:
> >
> >   
> >> James Bensley wrote:
> >>     
> >>> Shadies and Mentlemen;
> >>>
> >>> I am trying to be green and put our backup servers to sleep during the
> >>> day and have them wake on LAN and fire back up at night for our
> >>> nightly backups as "sleep" is a sort of low power usage mode.
> >>>
> >>> (At this point I would be curious to know the different levels of
> >>> sleep, what can I achieve? Does my server just drop into a low power
> >>> state, or can I stop the hard drives as well?)
> >>>
> >>> I am wondering if it is achievable to script the process of putting a
> >>> server to sleep so I can cron tab its behind!
> >>>
> >>> I would assume it would be possible but I don't know how, does anyone
> >>> have any idea?
> >>>   
> >>>       
> >> You are probably best of putting your backup server on an already
> >> running server as a virtual machine. If you really have only one server
> >> running on your lan then you could also consider the following approach.
> >> I use the power-on-time BIOS feature most MB have. My server start
> >> itself every night at 01:55. It is then up and running just before
> >> 02:00. At 02:00 I schedule a cron job to do the backup. At the end of
> >> the backup, the script just powers off the machine. The only thing to
> >> experiment with is the time it takes to start the machine. Sometimes the
> >> startup takes longer if disks need to be checked (ext3, every so may
> >> boots) and the cron might not trigger. Using anacron is perhaps the
> >> safest option in this case, but I did not experiment with that.
> >> I could not use wake up on LAN, since the mirror is on a remote location
> >> were it is really the only server.
> >>     
> >
> > You can also do a 'pull' backup -- the backup server runs the backup
> > job, not the 'active' server(s).  In this case, instead of cron jobs on
> > the active machines, you reference the backup script rc.local on the
> > backup server.
> >   
> Yes that is what I indeed do. The initiative is taken by the backup
> server, not by the server that needs to be backed up. In principle both
> can be done if machines can talk to each other when up and running. In
> my situation my backup server is behind a home nat router and cannot be
> reached from the internet.
> The rc.local is indeed also an option that does not need cron. In my
> particular situation, the backup server is also used for normal use
> during daytime so I don't want the backups to start always when the
> machine is powered.

One can always put a time check in the rc.local file (or the script it
starts).  Eg if time-of-day >= 2am and time-of-day < 2:30am then start
backup.  This allows for a slow boot up (eg slow fsck or something like
that). It is also possible for rc.local to start a backup daemon which
checks local system activity and might do a back at some other time if
the local load a really light and/or the time is some other 'dead of
night' period, such as at 3am or 4am, if it appears that the 2am backup
failed to start for some reason.  This also allows for a 'failsafe'
backup -- where you can arrange for the backup server to be fired up at
additional dead period times.

> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
> 
>                                                                                                         

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
heller at deepsoft.com       -- http://www.deepsoft.com/ModelRailroadSystem/
                                                            



More information about the CentOS mailing list