Manually splitting large disks: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
You may happen to run into the problem of having to back up more data than will fit onto a single tape, like when you have partitions that are much larger as a tape. Over time, the partition will hold more and more data, and if you started with a simple amanda configuration that backs up the partition as a whole, backups will fail sooner or later. Your shiny tape changer isn't all that helpful with this because amanda doesn't automagically change to the next tape to continue writing on it if the dump is too large. Upcoming versions of amanda might do that, though.
You may happen to run into the problem of having to back up more data than will fit onto a single tape, like when you have partitions that are much larger as a tape. Over time, the partition will hold more and more data, and if you started with a simple Amanda configuration that backs up the partition as a whole, backups will fail sooner or later. Your shiny tape changer isn't all that helpful with this because Amanda up to version 2.4.x doesn't automagically change to the next tape to continue writing on it if the dump is too large. (Amanda 2.5.0 is able to split DLEs.)


Thus, the need arises to virtually split partitions into parts so that each part remains smaller than a tape. This will lead to smaller single dumps so that amanda can continue the backup of other dumps on the next tape, if need be. One way to do that is creating appropriate entries in the [[disklist]].
Thus, with Amanda < 2.5.0 the need arises to virtually split partitions into parts so that each part remains smaller than a tape. This will lead to smaller single dumps so that Amanda can continue the backup of other dumps on the next tape, if need be. One way to do that is creating appropriate entries in the [[disklist]].


= Example =
= Example =

Revision as of 18:36, 30 March 2006

You may happen to run into the problem of having to back up more data than will fit onto a single tape, like when you have partitions that are much larger as a tape. Over time, the partition will hold more and more data, and if you started with a simple Amanda configuration that backs up the partition as a whole, backups will fail sooner or later. Your shiny tape changer isn't all that helpful with this because Amanda up to version 2.4.x doesn't automagically change to the next tape to continue writing on it if the dump is too large. (Amanda 2.5.0 is able to split DLEs.)

Thus, with Amanda < 2.5.0 the need arises to virtually split partitions into parts so that each part remains smaller than a tape. This will lead to smaller single dumps so that Amanda can continue the backup of other dumps on the next tape, if need be. One way to do that is creating appropriate entries in the disklist.

Example

Let's assume that you have two large partitions, holding several directories and subdirectories like the following:

/home/
/home/andrew
/home/anne
/home/brian
[...]
/home/wanda
/home/zeus

/share/
/share/financial
/share/financial/company-a
/share/financial/company-b
/share/reports

You created entries in your disklist to back them up:

largehost /home        my-dumptype
largehost /share       my-dumptype

That worked fine, but now on each of the partitions, there's too much data to fit onto a single tape. You will have to split up the partitions to back them up.

Splitting it up, the easy part

Considering the /home partition, it becomes obvious that you could split it alphabetically. You would create disklist entries to back up each subdirectory by using wildcards. You also want to catch anything under /home that doesn't fit into the wildcard specifications, so there:

largehost /home_a /home {
  my-dumptype
  include "./a*"
}       1
largehost /home_b /home {
  my-dumptype
  include "./b*"
}       1
[...]
largehost /home_w /home {
  my-dumptype
  include "./w*"
}       1
largehost /home_z /home {
  my-dumptype
  include "./z*"
}       1
# catch all the rest of /home:
largehost /home_rest /home {
  my-dumptype
  exclude append "./[a-z]*"
}       1

Notice the use of the 'include' and 'exclude' options. They do what you would guess, i. e. include the files specified, or exclude them. The tricky part is to use different disk names ('/home_a', '/home_b', ...) on the same partition/mount point ('/home'). You can omit specifying the spindle.

Splitting it up, the more complicated part

The /share partition is a little more complicated to split because you have to deal with the subdirectories. We assume that there's so much data in some of the directories that you have to treat them by diving into the subdirectories. You need to catch /share, /share/financial, /share/financial/company-a, /share/financial/company-b and /share/reports:

largehost /share_financial_company-a /share/financial {
  my-dumptype
  include "./company-a"
}       2
largehost /share_financial_company-b /share/financial {
  my-dumptype
  include "./company-b"
}       2
largehost /share_financial_rest /share/financial {
  my-dumptype
  exclude append "./company-a"
  exclude append "./company-b"
}       2
#
largehost /share_reports /share {
  my-dumptype
  include "./reports"
}       2
#
largehost /share_rest /share {
  my-dumptype
  exclude append "./financial"
  exclude append "./reports"
}       2

In this example, it is important to notice that each subdirectory is refered to from its immediate parent directory. It doesn't work otherwise. The second thing to know is the usage of the 'exclude append' options. Using

exclude append "./financial ./reports"

will not work; you will get error messages about a wrong number of arguments in the reports created by amreport --- probably because of the spaces introduced, so be careful if you encounter directory names that contain spaces. It only works when using an 'exclude append' statement for each path (file, directory) that is to be excluded.

Otherwise, it works the same way as in the previous example.

See also

There are some important notes in the article on Exclude and include lists.