Announcement

Collapse
No announcement yet.

Considering backup with tar

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Considering backup with tar

    I'm considering to do regular backups with tar utility of entire and only disk with Linux system and my data. For backup purpose, I have an external disk big enough to store all my working disk. A few questions arise for me which I'd like you to help me to answer:
    1. What options should be set in order to have an ability to restore all of my system, system settings and data in the quickest and safest way in case of disk failure?
    2. There are system and data on my disk. When system is started, I guess, some files are (and being) open and modified by system. In particular, backup device (external disk) is enlisted in /media directory. Does it matter for backup/restore process?
    3. What steps should be performed, in case of failure entire disk and replacement with new one, to safely restore all of my system and data?

    Thanks for any help.

    #2
    Timeshift is a system restore utility which takes snapshots of the system at regular intervals. These snapshots can be restored at a later date to undo system
    changes. Creates incremental snapshots using rsync or BTRFS snapshots using BTRFS tools.

    Comment


      #3
      IF you want to use Tar here are the scripts I used before I retired 9 years ago. Cron may work differently now.

      Using tar scripts and CRON to back up

      These are the scripts I wrote to backup my Qt dev files at work (before I retired eight years ago!)

      There are three bash shell scripts listed below.
      They can be run manually or be added to a cron script as appropriate:
      backup_all.bsh can be put in the weekly cron
      backup_inc.bsh can be put into the daily cron
      restor_all.bsh is run manually when ever needed

      How to setup cron scripts is shown below the backup and restore scripts.

      The list of directories to back up or restore are in both backup scripts and should be identical. Modify them to suit your needs. They should not include the destination for the tar file which is created.
      "bkupdir" is the full path to the directory where the tar files that are created are stored. That directory should not be among those backed up.
      "bkupname" is the name that will be given to the file. Change the string portion to suit yourself.

      Consult the tar man for details on tar parameters and auxiliary files.

      backup_all.bsh
      ***************
      Code:

      #!/bin/bash
      #copyright 2004 Jerry L Kreps
      #released under the terms of the GNU General Public License
      bkupdir=/backup
      bkupname="Webserver_fullbkup_"$(date +'%Y-%m-%d')
      tar --create
      --gzip
      --sparse
      --same-permissions
      --file=$bkupdir/$bkupname.tgz
      --blocking-factor=256
      --directory=/
      --label=$bkupname
      /boot /etc /home /lib /misc /opt /root /sbin /selinux /usr /var 2> $bkupdir/backup_errors.txt &



      backup_inc.bsh
      ************************
      Code:

      #!/bin/bash
      #copyright 2004 Jerry L Kreps
      #released under the terms of the GNU General Public License
      bkupdir=/backup
      bkupname="Webserver_incbkup_"$(date +'%Y-%m-%d')
      tar --create
      --gzip
      --sparse
      --same-permissions
      --file=$bkupdir/$bkupname.tgz
      --blocking-factor=256
      --directory=/
      --label=$bkupname
      --listed-incremental=$bkupdir/webserver.snar
      /bin /boot /etc /home /lib /misc /opt /root /sbin /selinux /usr /var &




      "restore_all.bsh" is followed by the tar file which will be extracted as the first parameter.

      restore_all.bsh
      *********************
      Code:

      #!/bin/bash
      #copyright 2004 Jerry L Kreps
      #released under the terms of the GNU General Public License
      tar -xzsSpf --numeric-owner %1 2> /backup/restore_errors.txt





      Newbie: Intro to cron
      Date: 30-Dec-99
      Author: cogNiTioN <cognition@attrition.org>

      Cron

      This file is an introduction to cron, it covers the basics of what cron does,
      and how to use it.

      What is cron? ( Consult the man on cron and crontab for more details)

      Cron is the name of program that enables unix users to execute commands or
      scripts (groups of commands) automatically at a specified time/date.

      Cron is a daemon, which means that it only needs to be started once, and will
      lay dormant until it is required. The cron daemon, or crond, stays dormant
      until a time specified in one of the config files, or crontabs.

      On most Linux distributions crond is automatically installed and entered into
      the start up scripts. To find out if it's running do the following:

      cog@pingu $ ps aux | grep crond
      root 311 0.0 0.7 1284 112 ? S Dec24 0:00 crond

      The second line shows that crond is running.

      If it's not running then
      sudo /etc/init.d/cron start

      Using cron

      There are a few different ways to use cron (surprise, surprise).

      In the /etc directory you will probably find some sub directories called
      'cron.hourly', 'cron.daily', 'cron.weekly' and 'cron.monthly'. If you place
      a script into one of those directories it will be run either hourly, daily,
      weekly or monthly, depending on the name of the directory.

      If you want more flexibility than this, you can edit a crontab (the name
      for cron's config files). The main config file is normally /etc/crontab.


      jerry@jerry-sonylaptop:~$ cat /etc/crontab
      Code:

      # /etc/crontab: system-wide crontab
      # Unlike any other crontab you don't have to run the `crontab'
      # command to install the new version when you edit this file
      # and files in /etc/cron.d. These files also have username fields,
      # that none of the other crontabs do.

      SHELL=/bin/sh
      PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

      # m h dom mon dow user command
      17 * * * * root cd / && run-parts --report /etc/cron.hourly
      25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
      47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
      52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
      #


      The first part is almost self explanatory; it sets the variables for cron.

      SHELL is the 'shell' cron runs under. If unspecified, it will default to
      the entry in the /etc/passwd file.

      PATH contains the directories which will be in the search path for cron
      e.g if you've got a program 'foo' in the directory /usr/cog/bin, it might
      be worth adding /usr/cog/bin to the path, as it will stop you having to use
      the full path to 'foo' every time you want to call it.


      Here is part of /etc/crontab edited to show it executing backup_all.bsh every Sunday morning at 1AAM
      and doing the incremental backups at 1AM every Mon thru Fri morning. /backup is an NFS mount to a second HD or remote server.
      Code:

      00 1 * * 7 root /backup/backup_all.bsh
      00 1 * * 1-5 root /backup/backup_inc.bsh
      17 * * * * root cd / && run-parts --report /etc/cron.hourly
      25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
      47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
      52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )




      Now for the more complicated second part of a crontab file.
      An entry in cron is made up of a series of fields, much like the /etc/passwd
      file is, but in the crontab they are separated by a space. There are normally
      seven fields in one entry. The fields are:

      m h dom mon dow user cmd

      m = minute This controls what minute of the hour the command will run on,
      and is between '0' and '59'
      h = hour This controls what hour the command will run on, and is specified in
      the 24 hour clock, values must be between 0 and 23 (0 is midnight)
      dom This is the Day of Month, that you want the command run on, e.g. to
      run a command on the 19th of each month, the dom would be 19.
      mon This is the month a specified command will run on, it may be specified
      numerically (0-12), or as the name of the month (e.g. May)
      dow This is the Day of Week that you want a command to be run on, it can
      also be numeric (0-7) or as the name of the day (e.g. sun).
      user This is the user who runs the command.
      cmd This is the command that you want run. This field may contain
      multiple words or spaces.

      If you don't wish to specify a value for a field, just place a * in the
      field.

      e.g.
      01 * * * * root echo "This command is run at one min past every hour"
      17 8 * * * root echo "This command is run daily at 8:17 am"
      17 20 * * * root echo "This command is run daily at 8:17 pm"
      00 4 * * 0 root echo "This command is run at 4 am every Sunday"
      * 4 * * Sun root echo "So is this"
      42 4 1 * * root echo "This command is run 4:42 am every 1st of the month"
      01 * 19 07 * root echo "This command is run hourly on the 19th of July"

      Notes:

      Under dow 0 and 7 are both Sunday.

      If both the dom and dow are specified, the command will be executed when
      either of the events happen.
      e.g.
      * 12 16 * Mon root cmd
      Will run cmd at midday every Monday and every 16th, and will produce the
      same result as both of these entries put together would:
      * 12 16 * * root cmd
      * 12 * * Mon root cmd

      Vixie Cron also accepts lists in the fields. Lists can be in the form, 1,2,3
      (meaning 1 and 2 and 3) or 1-3 (also meaning 1 and 2 and 3).
      e.g.
      59 11 * * 1,2,3,4,5 root backup.sh
      Will run backup.sh at 11:59 Monday, Tuesday, Wednesday, Thursday and Friday,
      as will:
      59 11 * * 1-5 root backup.sh

      Cron also supports 'step' values.
      A value of */2 in the dom field would mean the command runs every two days
      and likewise, */5 in the hours field would mean the command runs every
      5 hours.
      e.g.
      * 12 10-16/2 * * root backup.sh
      is the same as:
      * 12 10,12,14,16 * * root backup.sh

      */15 9-17 * * * root connection.test
      Will run connection.test every 15 mins between the hours or 9am and 5pm

      Lists can also be combined with each other, or with steps:
      * 12 1-15,17,20-25 * * root cmd
      Will run cmd every midday between the 1st and the 15th as well as the 20th
      and 25th (inclusive) and also on the 17th of every month.
      * 12 10-16/2 * * root backup.sh
      is the same as:
      * 12 10,12,14,16 * * root backup.sh

      When using the names of weekdays or months, it isn't case sensitive, but only
      the first three letters should be used, e.g. Mon, sun or Mar, jul.

      Comments are allowed in crontabs, but they must be preceded with a '#', and
      must be on a line by them self.
      ....

      Additional Reference:
      Man pages: cron(Cool crontab(5) crontab(1)
      Book: _Running Linux_ (O'Reilly ISBN: 1-56592-469-X)
      © Copyright 2000 cogNiTioN <cognition@attrition.org>
      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
      – John F. Kennedy, February 26, 1962.

      Comment


        #4
        Better than Tar is using btrfs as your filing system so that snapshot can be used. Far and away the easiest way to backup and recover.
        "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
        – John F. Kennedy, February 26, 1962.

        Comment

        Working...
        X