What directories do I need to back up?
What are the directories one should back up, in order to have a backup of all user-generated files? From a vanilla debian install, I can do enough apt to get the packages that I want. So if I don’t want to backup the entire system, where all in the filesystem do user-generated configuration and data files reside?
Missing in all of these answers is what happens after you back the files up. Do you just copy them back once the new install completes? What problems could arise when you do that?
I think I’m just identifying a flaw that even Linux has. Hopefully maybe it will affect future design of the OS.
+1 for not using «backup» as a verb. I get tired of seeing otherwise intelligent people use it that way.
7 Answers 7
As this question has many different answers, the following list should combine the suggestions into one comprehensive list:
Under most circumstances you want to backup these:
- /home/ for user data and configuration.
- /etc/ for system wide configuration files.
- /var/ contains a mix of directories you usually want to backup and those you don’t want to backup. See below for a more detailed explanation.
Some more directories to consider are:
- /usr/local/ hand-installed packages (i.e. not installed through apt) are installed here. If you have packages installed here, you may want to backup the whole directory, so you don’t have to reinstall them. If the packages themselves aren’t important to you, it should be enough to backup /usr/local/etc/ and /usr/local/src/ .
- /opt/ if you didn’t store anything here, you don’t need to back it up. If you stored something here, you are in the best position to decide, if you want to back it up.
- /srv/ much like /opt/ , but is by convention more likely to contain data you actually want to backup.
- /root/ stores configuration for the root user. If that is important to you, you should back it up.
/var/
/var/ contains many files you want to backup under most circumstances, but also some you don’t want to backup.
You probably want to backup these:
- /var/lib/ this directory contains variable state data for installed applications. Depending on the application you want to backup that state or you don’t. If you want to be on the safe side, you can just back up everything. Otherwise you can look at each sub-directory and decide for yourself if the data contained is important enough to you to back it up.
- /var/mail/ you normally want to backup local mails.
- /var/www/ if your web root is located here and this is the only place where your web content is stored, you want to back it up.
- /var/games/ you may want to backup these, if system wide game data is important enough for you (not many games use this storage though).
- /var/backups/ usually contains files that are automatically generated from other data that you usually want on a backup, but that would take an unnecessary amount of space in the backup or is otherwise cumbersome to backup. For example dpkg dumps a list of installed packages here, so you can later know which packages to install after restoring the backup. You probably want to backup this.
- /var/spool/cron/crontabs/ might contain many commands or a complex schedule, even with dependencies on other systems, that has taken considerable effort to put together.
You probably don’t want to backup these:
- /var/cache/ contrary to the name, some contents of this directory are important, so check each subdirectory individually, as a rule of thumb, everything you put here yourself is important. You also might want to backup /var/cache/debconf/ .
- /var/lock/ locks usually (always) don’t need to be backed up.
- /var/run/ contains data that is only important for your running system, i.e. when you shutdown you system, it will not be needed any more.
- /var/spool/ (other than /var/spool/cron/crontabs , see above) normally important data shouldn’t be stored here, but you might want to check.
You have to decide yourself on these:
- /var/local/ you normally know if you stored something here and whether you want it on a backup or not.
- /var/opt/ see /var/local/ or better check if something important is stored here.
- /var/log/ depends on whether your logs are important to you and if you have enough space to store them (they might take a lot of backup space over time).
what is the default location for backup files of another server
I have an Ubuntu Server and one of its «tasks» is to mirror/backup files located on another server in a different location using rsync/rdiff-backup. I know there are some conventions like web pages go in /var/www. What is the best-practice/default location for storing the backup files? Possible places I considered: /var/backup — looks like it is used for internal backups of the OS /home/backup — I could create this directory, but if maintaining backups is a «service» this server provides, I feel it is wrong to put the files in the same folder with personal user files PS I am aware this question might be subjective (I got the warning tooltip), but I think what I do is quite common, and there has to be a convention.
2 Answers 2
There is a proper location.
There is a standard for proper filesystem structure. Its current version has been around for over a decade, which might be news to some Linux distros.
The latest version of the Filesystem Hierarchy Standard is 2.3: http://www.pathname.com/fhs/pub/fhs-2.3.html
There, under the «Purpose» section of var , it explains why that’s a bad idea to use /var/backups :
Several directories are `reserved’ in the sense that they must not be used arbitrarily by some new application, since they would conflict with historical and/or local practice. They are:
/var/backups /var/cron /var/msgs /var/preserve The proper place would be, dependent on the application and its usage, something like:
/var/lib//backups /var/local//backups /var/opt//backups (I say «something like» because whether you use /var/lib , /var/local , or /var/opt is dependent on the application, its role within the system, and how it was installed. Also, the structure under /var/lib/ is arbitrary based on the application maintainers.)
By the way, since you mentioned it, /var/www is not the proper place for served web pages (again, this is news to some distro and package maintainers, but the FHS is older that many of them who clearly never have read it). Served content, and stored application data/assets for services belong under the /srv directory. I have been using the protocol method since 2005 and find it works quite well ( /srv/http , /srv/ftp , /srv/git , /srv/svn , etc.).
Let’s say that that you are using rsync and that this machine is providing a backup service for the network, you would use:
UPDATE
In the end I actually decided to use /srv/rdiff-backup next /srv/git and /srv/svn and I am glad you confirmed this is the correct decision.
The Filesystem Hierarchy Standard 3.0 (March 19, 2015) is here refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
There is no default location.
I would not use any of the regular directories for this. Keep the server clean from outside backups and put those is a clear defined location.
Most likely I would use a removable disk and mount it. Something like /external_backups / or /media/external_backups/ and inside that subdirectories with the server name and inside those compressed tar files.
/home/backup feels wrong; I would leave /home/ itself for users. If you want to do it this way I would create a user «backup» and the same setup as above.
Something like this (2x with a partition, 2x from a /home/backup/ :
- /external_backups/AS400/20150101/backup.tar.gz
- /external_backups/AS400/2015_01_01.tar.gz
- /home/backup/AS400/20150101/backup.tar.gz
- /home/backup/AS400/2015_01_01.tar.gz
/var/backup is for internal usage indeed. The Debian package system keeps an older copy from the last but one dpkg run in /var/lib/dpkg/status-old . (By default:) In order to preserve the system for greater damage when a crash or filesystem corrupting occurs a daily backup is put into /var/backups when the file differs from the last copy. This is done from /etc/cron.daily/standard .
But there is no correct or wrong way to it (well, I discard the insane methods: like putting them in / or in /boot or something else as crazy as that).
Which are the most important directories to backup on a Linux server?
I’m running an Ubuntu 9.10 Linux server. I’m trying to find a way to backup the machine while it is running and from what I see, this eliminates the disk clone utilities. All of the disk clone stuff I have seen for Linux requires that you reboot into a special live CD. So my question is this, what is the best solution for backing up the system while it is running? Also, I don’t really care about the OS config too much, I just want to be able to keep my stored files and my programs that I have installed on it. Thanks
3 Answers 3
The important directories are /etc , /home , /var , and /srv . You may want to add /root , and remove unneeded bits from /var .
rsync is good if you want the files to be directly accessible, tar is fine if you don’t.
Ok thanks for that info. Are there any disk clone backups that support «live» backups? Backups that don’t require me to shutdown or deal physically with the server (such as put a CD in).
@Ashesh: In the end it’s up to the person performing the backup to determine which files are truly important to them.
I agree with Ignacio Vazquez-Abrams about /etc/ /home/ and some parts in /var/.
But don’t forget to save a list of the installed packages, so you know what programs was installed.
dpkg --get-selections > dpkg.list I’m using backup2l to backup my Debian server (AFAIK Ubuntu is a derivative of Debian). If configured correctly it automates your backup, e.g. getting the dpkg selections, creating differential and incremental backups (depending on your settings) and storing it in an archive. A post backup hook triggers rsync which syncs my archive with a remote copy.
I’m backing up /etc /var (with some exclusions like caches), /root , /home . Just think about what you have changed in addition to that and add it to the list. I for instance dump my sql databases in a special directory and save it, too.
You must log in to answer this question.
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.