http://wiki.zmanda.com/api.php?action=feedcontributions&user=Aayala&feedformat=atomThe Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC) - User contributions [en]2024-03-29T12:00:07ZUser contributionsMediaWiki 1.35.5http://wiki.zmanda.com/index.php?title=User:Aayala&diff=8788User:Aayala2013-03-19T22:39:26Z<p>Aayala: Blanked the page</p>
<hr />
<div></div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What_is_a_DLE%3F&diff=8787FAQ:What is a DLE?2013-03-19T22:31:15Z<p>Aayala: Created page with '{{FAQ Header}} A posting from the amanda-users mailing-list (amanda-users@amanda.org) asked: :"What, please, is a "DLE"? May it mean: Down Loadable Entity ??? Stupid. Do Less Er…'</p>
<hr />
<div>{{FAQ Header}}<br />
A posting from the amanda-users mailing-list (amanda-users@amanda.org) asked:<br />
<br />
:"What, please, is a "DLE"? May it mean: Down Loadable Entity ??? Stupid. Do Less Errors ??? Stupid again. Hmmmm ..."<br />
<br />
People consulting the amanda-users-mailinglist for the first time often get confused by the use of the abbreviation DLE.<br />
It has become very common for regular mailinglist-participants to use the abbreviation DLE, which means, in its long form, "[[disklist|'''d'''isk'''l'''ist]] '''e'''ntry".<br />
<br />
A DLE refers to one entry in the [[disklist]] of an Amanda-configuration. General usage was to describe them as partitions, or file systems. But in fact they do not have to be either. They can be directory trees, or multiple trees, or trees with some branches cut off. So the more generic term DLE was coined.<br />
<br />
(from http://www.amanda.org/docs/topten.html#id347521)<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What_is_%27bumping%27%3F&diff=8786FAQ:What is 'bumping'?2013-03-19T22:30:49Z<p>Aayala: Created page with 'The term "bumping" is used to describe the change from one backup-level to the next higher level. If Amanda changes from Level 0 to Level 1 for a specific DLE, it "[[Bump|bum…'</p>
<hr />
<div>The term "bumping" is used to describe the change from one backup-level to the next higher level. If Amanda changes from Level 0 to Level 1 for a specific [[DLE]], it "[[Bump|bumps]]".<br />
<br />
The basic goal of "bumping" is to save precious space on the backup media as higher level incremental backups are smaller in size than lower level incremental backups.<br />
<br />
The disadvantage of increasing backup levels is the fact that restoring from higher level incremental backups needs more tapes. This increases the amount of work time needed to fully restore a DLE as well as the possibility of tape-errors and similar problems during the process of restore. So in general it is recommended to keep the levels as low as possible with the given hardware and data.<br />
<br />
There are various {{man|5|amanda.conf}} parameters to control and fine-tune Amanda's behavior when it comes to bumping. Please refer to the amanda-manpage and the example amanda.conf for details on the parameters <tt>bumppercent</tt>, <tT>bumpsize</tt>, <tt>bumpdays</tt> and <tt>bumpmult</tt>.</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What_versions_of_GNU_Tar_are_Amanda-compatible%3F&diff=8785FAQ:What versions of GNU Tar are Amanda-compatible?2013-03-19T22:29:35Z<p>Aayala: Created page with '__NOTOC__ Amanda makes some heavy demands of GNU tar (sometimes known as gnutar or gtar), so some versions of tar will not work with some versions of Amanda. Note that many ve…'</p>
<hr />
<div>__NOTOC__<br />
Amanda makes some heavy demands of GNU tar (sometimes known as gnutar or gtar), so some versions of tar will not work with some versions of Amanda. <br />
<br />
Note that many vendors [https://www.redhat.com/advice/speaks_backport.html backport] fixes to earlier versions. For example, RedHat's tar-1.14 contains the fixes that were published in tar-1.15.1.<br />
<br />
<table width="100%" border="1"><br />
<tr><th>&nbsp;</th><th>Amanda-2.5.1p2 and earlier</th><th>Amanda-2.5.1p3 and later</th></tr><br />
<tr><th>1.13.19</th><td>Good<sup>1</sup></td><td>Good<sup>1</sup></td></tr><br />
<tr><th>1.13.25</th><td>Good</td><td>Good</td></tr><br />
<tr><th>1.13.9x</th><td>Bad<sup>2</sup></td><td>Bad<sup>2</sup></td></tr><br />
<tr><th>1.14.x</th><td>Commonly Bad<sup>3</sup></td><td>Commonly Bad<sup>3</sup></td></tr><br />
<tr><th>1.15.1</th><td>Good</td><td>Good</td></tr><br />
<tr><th>1.16 and above</th><td>Bad<sup>4,5</sup></td><td>Good</td></tr><br />
<tr><th>1.24 and 1.25</th><td>Bad<sup>6</sup></td><td>Bad<sup>6</sup></td></tr><br />
<tr><th>1.26</th><td>Good</td><td>Good</td></tr><br />
</table><br />
<br />
= Notes =<br />
;1:Tar 1.13.19 sets return code 2 for some infrequent conditions even with --ignore-failed-read option. This results in Amanda thinking the total archive is bad, and drops the complete archive. Those conditions are very rare on a quiet filesystem.<br />
;2:Tar 1.13.9x has changed the format of "tar -t", resulting in amrecover not able to use the indexes.<br />
;3:Tar 1.14.x writes good archives, but when restoring, it has trouble with sparse files: the sparse file itself, and ''all'' files after it cannot be read anymore. But you can read the archive with a good tar version (the tar images produced are fine -- it just can't read them correctly). If you are using Red Hat Enterprise Linux, this has been fixed by a [https://www.redhat.com/advice/speaks_backport.html backport]; Please make sure you are using the most recent RHEL tar package and, if needed, use the --nodeps flag when installing Amanda using rpm.<br />
;4:See http://marc.info/?l=amanda-users&m=117621620031671&w=2. Tar 1.16 returns 1 when it sees size of a file changes. It's a new behavior that breaks Amanda prior to Amanda-2.5.1p2. See also [http://lists.gnu.org/archive/html/bug-tar/2007-03/msg00055.html Re: [Bug-tar<nowiki>]</nowiki> --ignore-failed-read not applied to files changing as tar reads them].<br />
;5:The format of the --listed-incremental snapshot files changed after tar 1.15.1. Among other differences, the entry separator used in the file changed from a newline to a null byte. Because of the way amanda prior to amanda-2.5.1 reads in these files, this would cause backups and estimates of incremental dumps to behave improperly or fail.<br>Note: The table above says that amanda-2.5.1p2 is required if using tar > 1.15.1. This particular issue was fixed in amanda-2.5.1 (but <sup>4</sup> still applies).<br />
;6:These versions have a fatal flaw which causes backups to only contain the root directory and no files. See http://www.mail-archive.com/bug-tar@gnu.org/msg02999.html , http://thread.gmane.org/gmane.comp.sysutils.backup.amanda.general/37932 , and http://www.mail-archive.com/bug-tar@gnu.org/msg03187.html .<br />
<br />
== Other References ==<br />
* http://marc.info/?t=98095323900002&r=1&w=2<br />
* http://www.amanda.org/docs/faq.html#id347035<br />
* [[Installation/Amanda's Requirements]]<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:Should_I_use_a_holdingdisk_when_the_final_destination_of_the_backup_is_a_virtual_tape%3F&diff=8783FAQ:Should I use a holdingdisk when the final destination of the backup is a virtual tape?2013-03-19T22:25:56Z<p>Aayala: Created page with '{{FAQ Header}} Usually the answer is "yes"! Holding disks and vtapes serve a complete different purpose: holding disk allows different clients to backup simultaneously …'</p>
<hr />
<div>{{FAQ Header}}<br />
Usually the answer is "yes"!<br />
<br />
[[Holding disk]]s and [[vtape]]s serve a complete different purpose: holding disk allows different clients to backup simultaneously and the server collects the incomplete images in the holding disk.<br />
When a backup image is complete, the server then adds it to the tape queue.<br />
The taper can choose the best file, depending on the criteria you set in "[[taperalgo]]".<br />
Especially "taperalgo largestfit" is helpful fitting as much as possible on a vtape. <br />
(e.g. when you want to burn the backups to a DVD later).<br />
<br />
When you do not specify a holding disk, then only one [[DLE]] can be dumped at once. No parallelism is possible. And taper cannot use any of its algorithms either. This is true even when using vtapes.<br />
<br />
In the case where you have only one client (e.g. your home PC),<br />
then avoiding a holding disk could indeed be a reasonable decision. <br />
But if your vtapes live on a slow USB-1 connected device, then a holding disk might<br />
still be faster.<br />
In case there are problems with your vtapes (e.g. the external disk with vtapes<br />
is full, or got disconnected), then Amanda can still fall back to degraded mode, <br />
and dump only incrementals to the holding disk.<br />
<br />
= Credit =<br />
Based on text by Stefan G. Weichinger, November - December, 2003, with updates in April, 2005.<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What%27s_the_difference_between_a_vtape_and_VFS_device%3F&diff=8782FAQ:What's the difference between a vtape and VFS device?2013-03-19T22:23:55Z<p>Aayala: Created page with '{{FAQ Header}} == vtapes, tapes, and volumes == When Amanda was first written, it only did backups to actual tapes - plastic boxes with long strips of magnetic material. So the …'</p>
<hr />
<div>{{FAQ Header}}<br />
== vtapes, tapes, and volumes ==<br />
When Amanda was first written, it only did backups to actual tapes - plastic boxes with long strips of magnetic material. So the word "tape" appears all over Amanda's documentation and messages. Later, Amanda introduced backups to disk. This feature basically emulated tapes on disk, and so these were called vtapes. This name is still used quite often in documentation and on the mailing list. <br />
<br />
In general, we try to refer to units of data storage as "volumes". For physical tapes, this means the same thing as "tape". For backups to disk, this means the same thing as "vtape". For Amazon S3 backups, we have always used the term "volume," because "s3tape" just sounds silly.<br />
<br />
== devices ==<br />
In Amanda-2.6.0, Amanda introduced a new [[Device API]] which completely rewrote all of code to read and write data to storage media. This introduced the concept of a device, which is analogous to a tape drive: a device is a tool to read and write on a volume. Each device has a "prefix" which is used to identify it in an Amanda configuration. Here is a partial list of devices. See {{man|7|amanda-devices}} for the full, current list.<br />
<br />
;Tape Device: Real, old-fashioned tapes. Prefix is <tt>tape:</tt> (or no prefix at all, for backward compatibility)<br />
;VFS Device: Backup to disks, a.k.a. vtapes. Prefix is <tt>file:</tt>.<br />
;S3 Device: Backup to Amazon S3. Prefix is <tt>s3:</tt>.</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What%27s_the_difference_between_a_device_and_a_changer%3F_Between_tapedev_and_tpchanger%3F&diff=8781FAQ:What's the difference between a device and a changer? Between tapedev and tpchanger?2013-03-19T22:23:22Z<p>Aayala: Created page with '{{FAQ Header}} = Devices and Changers = The best way to distinguish a device from a changer is by analogy to real, physical tapes. If you want to use more than one tape in your…'</p>
<hr />
<div>{{FAQ Header}}<br />
<br />
= Devices and Changers =<br />
The best way to distinguish a device from a changer is by analogy to real, physical tapes. If you want to use more than one tape in your Amanda configuration, you need:<br />
* some tapes<br />
* a drive<br />
* something to swap tapes (either a robot or a junior sysadmin)<br />
<br />
Amanda's terms for these are, respectively:<br />
* volumes<br />
* devices<br />
* changers<br />
<br />
When Amanda needs a tape, it asks the changer for a device, and the changer does whatever's necessary - moving a tape into a drive or adjusting some symlinks for vtapes - and returns an appropriate device.<br />
<br />
The model gets a little less obvious for things like VFS devices and Amazon S3, but it's still there! For S3 backups, for example, each volume has its own device, e.g.,<br />
;Volume: DailySet-004<br />
;Device: <tt>s3:mybucket/TAPE-004</tt><br />
;Changer: <tt>chg-multi:s3:mybucket/TAPE-{001,002,003,004,005,006,007}</tt><br />
<br />
= Configuration (tapedev and tpchanger) =<br />
New configurations only need to specify a changer. That changer will produce devices. In order to ensure backward compatibility, that changer can be specified in ''either'' <tt>tapedev</tt> or <tt>tpchanger</tt>. So, for example<br />
tpchanger "chg-disk:/path/to/vtapes"<br />
or<br />
tapedev "chg-robot:/dev/sg2"<br />
or<br />
tpchanger "my-changer-config"<br />
define changer "my-changer-config" {<br />
...<br />
}<br />
<br />
If you are looking at an older configuration, you may find both set along with some other options, e.g.,<br />
tpchanger "chg-zd-mtx"<br />
tapedev "/dev/nst0"<br />
changerdev "/dev/sg0"<br />
changerfile "/etc/amanda/myconfig/changer.conf"<br />
<br />
If you have such a configuration, it ''should'' still work. If you want to upgrade it to use functionality available in newer versions of Amanda, consult the mailing list or #amanda.<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:How_do_I_make_Amanda_do_full_backups_on_weekends_and_incrementals_during_the_week%3F&diff=8780FAQ:How do I make Amanda do full backups on weekends and incrementals during the week?2013-03-19T22:12:32Z<p>Aayala: Created page with '{{FAQ Header}} This question usually takes the forms: * "How do I make Amanda do full backups on Saturday and incrementals ... ?" * "My backup screwed up on tuesday and now it ke…'</p>
<hr />
<div>{{FAQ Header}}<br />
This question usually takes the forms:<br />
* "How do I make Amanda do full backups on Saturday and incrementals ... ?"<br />
* "My backup screwed up on tuesday and now it keeps asking for the tuesday tape even though it is wednesday!"<br />
<br />
The short answer is: You can't.<br />
<br />
The longer answer is: You can. But you should not.<br />
<br />
The reason: Amanda is designed to schedule your backups. Let "her" do it.<br />
<br />
When you want to make the best use of Amanda, you have to let go the classic schedule where one used to have one tape dedicated to each day of the week, and one for the friday.<br />
<br />
The main difference in concept is this:<br />
<br />
In the classic backup scheme you said:<br />
<br />
:"I want to have incremental backups from Mo-Th and a full backup on Fr."<br />
<br />
Using Amanda you say:<br />
<br />
:"I want to have at least one full backup in 5 days."<br />
<br />
So you don't have to specify exactly WHEN the full backup should happen. You just tell Amanda some goals it should reach and let it work out the details.<br />
<br />
There are several advantages in this:<br />
<br />
Imagine that you have your classic backup-schedule running fine. Everything is calculated and designed well, so your tape gets filled well each night. Now one user generates an unforeseen huge amount of data. For example, he duplicates one big data-directory by mistake. So the size of the directory raises within one day, maybe for multiple GBs.<br />
<br />
Would your classic backup-scheme catch that? Or would it run out of tape, simply because it was not calculated to have that filesystem with that size?<br />
<br />
Amanda would try to catch it (and most of the time succeed ...).<br />
<br />
As there is the estimate-phase before actually dumping something, Amanda can look at the [[DLE]]s and determine the actual size at the time. It also determines the size of an incremental backup so it can test for the Plan B to just run a level-1 if it does not work out to do a level-0 for that DLE.<br />
<br />
If the size of the DLE is much bigger than it has been the run before, Amanda still tries to meet your goals. It just reschedules stuff, combining full and incremental backups to meet the goals as good as possible.<br />
<br />
So you can think of it as some algorithm which lets Amanda adapt to your data. If you set the goals in a reasonable way, Amanda will just do the rest.<br />
<br />
(from http://www.amanda.org/docs/topten.html#id347894)<br />
<br />
<br />
== IF YOU INSIST ON DOING WEEKLY FULL BACKUPS DESPITE ALL THIS ADVICE ==<br />
<br />
This is not recommended procedure, but for environments that insist on weekly or monthly full backups.<br />
<br />
=== Method 1 ===<br />
* Edit amanda.conf to insure that incremental dump settings take more than a week to force the next full dump.<br />
* Edit amanda.conf to make sure that it includes a separate disklist.<br />
* Create a disklist.daily file. This is your reference disklist, and uses normal incremental dumps.<br />
* Create a script to edit disklist.daily into a disklist.full file, by replacing the dump options with "always-full" or a similar option.<br />
* Set your daily cron job for every day but Friday, to duplicate disklist.daily to disklist.<br />
* Set your Friday cron job to create disklist.full from disklist.daily, then duplicate disklist.full to disklist. Disklist.full is simply for reference for the next week, in case it's needed.<br />
<br />
=== Method 2 ===<br />
<br />
Another way using [http://wiki.zmanda.com/man/amanda.8.html Configuration Override] would be (no need to modify the disklist file)<br />
<br />
*Run amdump with parameter "-o DUMPTYPE:default:strategy=nofull" for every day except Friday (suppose you want to have full backup on Friday, and the dumptype is named 'default' in disklist).<br />
*Run amdump with parameter "-o DUMPTYPE:default:strategy=noinc" on Friday.<br />
<br />
Both works well as long as Friday's dumps are successful, and are completed before the next day's dumps begin. It's also extremely useful for scheduling full backups before major operating system upgrades or facility transfers, without interfering with your default system behavior.</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:How_are_backup_levels_defined_and_how_does_Amanda_use_them%3F&diff=8779FAQ:How are backup levels defined and how does Amanda use them?2013-03-19T22:11:05Z<p>Aayala: Created page with '{{FAQ Header}} <div>__TOC__</div> = Backup levels = Different backup software define backup levels in different ways, often using the same terms in contradictory ways. Amanda…'</p>
<hr />
<div>{{FAQ Header}}<br />
<div>__TOC__</div><br />
<br />
= Backup levels =<br />
<br />
Different backup software define backup levels in different ways, often using the same terms in contradictory ways. Amanda’s definition of backup levels follows the traditional Unix/BSD/Linux dump utility backup levels of 0-9, with level 0 being a full backup, and each level n being a backup of changes since the last backup of level n-1 or lower. Explanations and examples can be found in your system’s man pages for dump (or, e.g., ufsdump in Solaris). This system, and Amanda’s configuration parameters, are flexible enough to emulate virtually any backup scheme a user may be familiar with from previous experience with another piece of backup software. However, there are advantages to be gained from becoming familiar with Amanda’s backup planning strategy and from letting Amanda do the planning.<br />
<br />
For general reference, a new user may be wondering about how to do differential backups with Amanda. The typical definition of differential backup is the same as Amanda’s level 1 backup, and the reason a user may be interested in this is that it reduces the number of tapes required to recover a system. Their concern may arise from a definition of incremental backup that says changes since the last backup of any kind. With that definition, recovering a system would require every tape since the last full backup. Using Amanda’s standard backup planning strategy avoids that problem and typically gives the best result.<br />
<br />
Because different backup software may have conflicting definitions, it is important to get a specific definition for reference in asking or answering questions. For example, Symantec’s (Veritas) Netbackup defines a “differential-incremental” as only the changes since the last backup of any kind, and a “cumulative-incremental” as the changes since the last full backup. EMC Retrospect calls their backup IncrementalPLUS (“using patented technology”). However, the most common definitions of backup levels are those used by Amanda (0-9) and the set of definitions for full/incremental/differential in which incremental is changes since the last backup of any kind and differential is the changes since the last full backup.<br />
<br />
<br />
= Amanda’s planning strategy =<br />
<br />
Amanda’s strategy is one of optimization. Amanda balances the amount of tape or disk space used by a given level of incremental against the number of tapes that will be required to recover a system. Amanda is also balancing the usage of resources (network bandwidth, tape space, backup time) across the dump cycle (typically 5 or 10 days) to smooth out demands and avoid excessive spikes. <br />
<br />
Amanda’s default strategy has years of experience incorporated into it and works well in most situations. The guarantee is that you will get at least one full backup of each Disk List Entry (DLE) during each dump cycle. You will have at least an incremental of each DLE on every run, so you are covered for every DLE for every run within the dump cycle. <br />
<br />
There are a number of parameters available for tuning Amanda’s strategy to specific environments. See [[bumping]] and {{man|5|amanda.conf}} for more detail. However, it might be best to wait and see. Amanda may take a dump cycle or two to get the full backups distributed (first time around they will pile up at the beginning) and to get a sense of what it is dealing with. After that, you will find the the fulls distributed over the dump cycle and the load smoothed out.<br />
<br />
= What constitutes “changes”? =<br />
<br />
Some backup programs that have their own backup procedures have issues with various kinds of changes to the file system. For example, what happens when a user moves files from one directory to another? Or deletes files? And what does the backup procedure do to the file attributes?<br />
<br />
Amanda uses native utilities for its backup procedures. This not only gives the user freedom to choose, but also assures the highest likelihood of correct behavior.<br />
<br />
For example, testing with ufsdump/ufsrestore on Solaris 9 shows that the incremental backup captures the changes described above. Doing a ufsrestore of a full followed by an incremental correctly restores the directory structure and contents to account for moves and deletes. ufsdump also works off the raw device and does not affect atime. <br />
<br />
Gnutar uses tar extensions to implement incremental backups (see http://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html), and captures metadata that allows it to restore a directory structure to the state it was in when the incremental backup was done. Gnutar will affect atime. Attempting to get around this using the --atime-preserve=replace option is not a good idea, because it affects ctime (by changing atime back).<br />
<br />
Amanda works well with Gnutar or dump, and understands the options required to achieve the desired results. Much of this information is available from the man pages, and can be checked for whatever backup procedure is chosen.</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:I%27m_seeing_%22Request_to_AMANDA_CLIENT_failed:_timeout_waiting_for_ACK%22&diff=8778FAQ:I'm seeing "Request to AMANDA CLIENT failed: timeout waiting for ACK"2013-03-19T22:09:56Z<p>Aayala: Created page with '{{FAQ Header}} This is a common error with the BSD-style Amanda authentications. These authentications are difficult to configure and offer minimal security. If possible, consi…'</p>
<hr />
<div>{{FAQ Header}}<br />
This is a common error with the BSD-style Amanda authentications. These authentications are difficult to configure and offer minimal security. If possible, consider using "local" auth (which only works for the local host, and is only available in Amanda-2.6.0 and later) or "ssh" auth. See {{man|7|amanda-auth}} for details.<br />
<br />
If this is not possible, see the corresponding troubleshooting article, [[planner: ERROR Request to AMANDA CLIENT failed: timeout waiting for ACK]].</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:Amanda_has_been_running_fine_for_years,_and_just_stopped&diff=8777FAQ:Amanda has been running fine for years, and just stopped2013-03-19T22:09:21Z<p>Aayala: Created page with '{{FAQ Header}} This is a common problem reported by new admins of Amanda configs that have been working since the last admin left. This is almost always because a disk has grown…'</p>
<hr />
<div>{{FAQ Header}}<br />
This is a common problem reported by new admins of Amanda configs that have been working since the last admin left.<br />
<br />
This is almost always because a disk has grown far larger than the size when the Amanda configuration was last adjusted. Amanda sends daily report emails which contain enough information to anticipate these problems and configure around them.<br />
<br />
Most often, the problem is one of the following:<br />
<br />
== Estimate Timeouts ==<br />
As a disk, especially on an older, slower machine, grows in size and number of files, Amanda's estimate of the size of that disk will take longer and longer. Eventually, this can exceed Amanda's configured estimate timeout (<tt>etimeout</tt>), usually triggering a [[Results missing]] error message.<br />
<br />
== Oversized Dumps ==<br />
Similarly, a large disk may no longer fit on a single tape, or the combination of all [[DLE]]s may no longer fit on a tape. This can be especially problematic for systems where tape spanning is not enabled, or if <tt>runtapes</tt> is set to 1. See:<br />
* [[How To:Split Dumps Across Tapes]]<br />
* [[How To:Split DLEs With Exclude Lists]]<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:What_is_the_difference_between_Amanda_and_Zmanda%3F&diff=8776FAQ:What is the difference between Amanda and Zmanda?2013-03-19T22:05:47Z<p>Aayala: Created page with '{{FAQ Header}} Amanda is the open source backup application. Zmanda is the company sponsoring Amanda's development. For more details, see [http://www.zmanda.com/amanda-enterpri…'</p>
<hr />
<div>{{FAQ Header}}<br />
Amanda is the open source backup application. Zmanda is the company sponsoring Amanda's development.<br />
<br />
For more details, see [http://www.zmanda.com/amanda-enterprise-faq.html Amanda Enterprise FAQ].<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:Where_should_I_ask_questions%3F&diff=8775FAQ:Where should I ask questions?2013-03-19T22:04:26Z<p>Aayala: Created page with '{{FAQ Header}} There are several channels available for Amanda support: * The [http://www.amanda.org/support/mailinglists.php amanda-users@amanda.org] mailing list * The [http://…'</p>
<hr />
<div>{{FAQ Header}}<br />
There are several channels available for Amanda support:<br />
* The [http://www.amanda.org/support/mailinglists.php amanda-users@amanda.org] mailing list<br />
* The [http://forums.zmanda.com Amanda forums]<br />
* [http://www.amanda.org/support/irc.php #amanda on IRC]<br />
* The [http://network.zmanda.com/ Zmanda Network] provides whitepapers and live webinars. Free registration is required.<br />
{{Languages}}</div>Aayalahttp://wiki.zmanda.com/index.php?title=FAQ:How_do_I_force_Amanda_to_do_a_full_backup%3F&diff=8774FAQ:How do I force Amanda to do a full backup?2013-03-19T21:51:06Z<p>Aayala: Created page with '{{FAQ Header}} You can use amadmin command to force Amanda to do full (level 0) backup in the next backup run (next execution of {{man|8|amdump}} command). For example, amad…'</p>
<hr />
<div>{{FAQ Header}}<br />
You can use [[amadmin]] command to force Amanda to do full (level 0) backup in the next backup run (next execution of {{man|8|amdump}} command). For example,<br />
amadmin <amanda configuration> force <Amanda client> <Amanda client directory><br />
<br />
You can use {{man|8|amadmin}} command to control Amanda planner algorithm.</div>Aayalahttp://wiki.zmanda.com/index.php?title=User:Mark_Kohler&diff=8762User:Mark Kohler2012-12-04T19:52:46Z<p>Aayala: Blanked the page</p>
<hr />
<div></div>Aayala