Month: March 2021

How to use rsync to backup an entire server?

Yes, It is possible to backup entire server files using rsync over the network to another server or to a locally attached disk. rsync is easy to set up but it is not a complete backup solution. Make sure you should not use rsync to backup server files to tape devices. You could completely clone a server but it is the slowest backup method. You should back up only the data and use third-party cloning tools to backup system files.

You can use rsync to perform differential backups so later backups only copy files that are changed since the last backup is done. It should be noted that rsync cannot backup online databases so use third party software like cPanel to backup databases. You should use following options with rsync:

ownerships, permissions, preserve timestamps, extended attributes (to preserve SELinux attributes), and ACLs.

Make sure you use the same rsync version on source and destination servers.

  • To backup server filesystem to an external disk (attached with USB or other hardware) and mounted as /media

rsync -AXav --progress --del --exclude "/sys/*" --exclude "/media/*" --exclude "/proc/*" --exclude "/selinux/*" --exclude "/mnt/*" / /media/

  • To backup server filesystem over a network to another server (which is computing.seimaxim.com in this How-To):

rsync -AXavz –progress –del –bwlimit=1000 –exclude “/sys/*” –exclude “/selinux/*” –exclude “/proc/*” –exclude “/media/*” –exclude “/mnt/*” / root@computing.seimaxim.com:/media/

In above command -z option is used for compression to increase data transfer speed.

 

 

How to resolve error resize2fs: Operation not permitted While trying to add group – ext4_group_add: No reserved GDT blocks, can’t resize

The root cause of this error is that the pool of reserved GDT blocks is not available, or the filesystem does not support online resizing. Note that the Ext3 and Ext4 filesystem metadata layout is fixed. mkfs reserves space for future disk resizing, but that is only 1024x the filesystem size during initial disk creation or the upper block count limit of 2^32, priority given to the lowest. The third root cause of the error is that the journal is too small.

  • To resolve this error:

check if online resizing is available for the filesystem. You can check this with resize_inode in the dumpe2fs output. If resize_inode text is not present in the dumpe2fs output given below, then the filesystem does not support online resizing. It would be best if you then unmounted the filesystem and then resize it.

dumpe2fs /dev/vg_test/lv_ext3 | grep -i features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Journal features: journal_incompat_revoke

  • Check the output of dumpe2fs. If the Reserved GDT block line is missing, then the GDT block count is 0. The solution, in this case, is to resize the filesystem offline, i.e., after unmounting the filesystem.
  • The third scenario is when resize fails in both offline and online mode. The solution, in this case, is to remove the journal while the filesystem is offline and recreate the journal with a larger size.

First, check the size of the journal with;

dumpe2fs /dev/vg_test/lv_ext3 | grep Journal\ size
Journal size: 32M

Now remove the journal with

tune2fs -O ^has_journal /dev/vg_test/lv_ext3
Creating journal inode: done

Verify the journal size you just create with;

dumpe2fs /dev/vg_test/lv_ext3 | grep Journal\ size
Journal size: 148M

Now resize with resize2fs /dev/vg_test/lv_ext3

If you still get errors, use the option -J size=journal-size, where journal-size is in megabytes.