You should add some methods to easily reconstruct the disk structure (partition table, file systems, mount points).
Also, an rsync
backup can horribly fail in some cases where file are kept open for a long time and are steadily updated. Database servers are prime examples for this - you can't reliably backup a running database with rsync
.
1. Excluding /var/run
As you already noticed, excluding /var/run
during a complete restore of a CentOS 6 system causes problems, because it also excludes directories created by installed packages. Excluding /var/lock
can also cause similar problems, because some packages create subdirectories there too.
(There may be no such issues on more recent Linux distributions which use systemd
— on such distributions /var/lock
and /var/run
(really /run
) may be placed on tmpfs
, and any required subdirectories are created during every boot; however, CentOS 6 is much older and does not have any support for automatic creation of subdirectories in /var/lock
or /var/run
.)
However, actually excluding /var/run
and /var/lock
is not needed for a proper restore, because the /etc/rc.d/rc.sysinit
script on CentOS 6 includes the following command:
find /var/lock /var/run ! -type d -exec rm -f {} \;
This command will remove all stale lock or pid files (or any other non-directory files, such as sockets and symlinks) during the system boot. Therefore you should remove /var/lock
and /var/run
from the restore exclusion list.
2. Location of network configuration files
You already exclude /etc/sysconfig/network*
when restoring the backup; this should match both the /etc/sysconfig/network
file (global networking configuration) and the /etc/sysconfig/network-scripts
directory (per-interface configuration files ifcfg-*
). However, these files are used only by the old-style network configuration scripts included in the initscripts
package, and CentOS 6 has another network configuration system — NetworkManager, configuration for which is stored in /etc/NetworkManager
. Try also excluding that directory when you restore the backup.
3. The issue with symbolic links replaced with files
If you see that symbolic links were replaced with plain files after the restore, this means that either your backup/restore program was not configured correctly, or (if there is no option for saving and restoring actual symlinks) the program you used is not suitable for Linux system backup/restore at all. You can get away with a program which does not support symlinks only if the program is used to backup and restore only some specific data which definitely will not contain symlinks. Note that you may find symlinks in places where you did not expect them — e.g., in some cases symlinks may be used in MySQL database directories (to store some parts of data on a different device), therefore relying on the “no symlinks” assumption may be dangerous.
4. MySQL backup
If your backup program simply copies files from a running server, your backup is not really “crash consistent“, because different files (and even different blocks of a same file) are copied at different times, therefore you will not actually get a consistent snapshot of the database in your backup. (This applies to any kind of database, not just MySQL.)
There are several ways to backup MySQL databases using just a file-level backup:
Use mysqldump
to create a SQL dump before starting the file-level backup; backup the dump file instead of the database directory. This is the most portable backup format, but both dumping and restoring may be slow.
Stop the MySQL server before starting the backup, make a file-level backup, then start the MySQL server again. To restore, just restore all files on the new server, then start the server normally. This kind of backup is fast, but requires a significant downtime during the backup.
To reduce the MySQL server downtime required by the previous method, you can create a filesystem snapshot after stopping the server, then start the MySQL server again, and then mount the snapshot, perform a file level backup and delete the snapshot. You need to have the filesystem on an LVM volume with some free space in the volume group for the snapshot.
To reduce the downtime even further, you can use FLUSH TABLES WITH READ LOCK
before taking the snapshot instead of stopping the server, as described here; in this case the snapshot will contain MyISAM tables in a consistent state, and InnoDB tables in a crash-consistent state (InnoDB recovery will be needed after a file level restore).
Read this documentation for more information about MySQL backup.
Best Answer
No. It backs up the contents of the filesystem.
Not the MBR which is not a file but is contained in a sector outside the file systems.
And not the filesystem with it potentially tweaked settings and or errors, just the contents of the file system (granted, that is a minor difference).
Probably, as long as you use the same setup. The tarball will just contain the files, not the partition scheme used for the disks. So you will have to partition the disk in the same way. (Or copy the old partition scheme, e.g. with
dd if=/dev/sda of=myMBRbackup bs=512 count=1
).Note that there are better ways to create backups, some of which already have been answered in other posts. Personally I would just backup the configuration and the data. Everything else is merely a matter of reinstalling. Possibly even with the latest version.
Also not that tar will backup all files. The first time that is a good thing.
But if you run that weekly or daily you will get a lot of large backups. In that case look at rsync (which does incremental changes) or one of the many other options.