From: Dihor 2. <dih...@ya...> - 2007-08-24 11:05:19
|
Item 1: Implement a Copy job type that will copy the job data from one device to another, for example, copy from a fiel Tape to a real Tape. Date: 24 Aug 2007 Origin: dihor2000 at yahoo.de Contact: dihor2000 at yahoo.de Daniel Holtkamp Status: Partially coded in 1.37 -- much more to do. Assigned to Kern. What: The ability to copy, move, or archive data that is on a device to another device is very important. Why: An ISP might want to backup to disk, but after 30 days migrate the data to tape backup and delete it from disk. Bacula should be able to handle this automatically. It needs to know what was put where, and when, and what to migrate -- it is a bit like retention periods. Doing so would allow space to be freed up for current backups while maintaining older data on tape drives. Notes: Migration could be triggered by: Number of Jobs Number of Volumes Age of Jobs Highwater size (keep total size) Lowwater mark Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER WELTENBUMMLER! www.yahoo.de/clever |
From: Dihor 2. <dih...@ya...> - 2007-08-24 11:15:58
|
Item 1: Implement a Copy job type that will copy the job data from one device to another, for example, copy from a fiel Tape to a real Tape. Date: 24 Aug 2007 Origin: dihor2000 at yahoo.de Contact: dihor2000 at yahoo.de Status: feature request Assigned to no one What: The ability to copy, data that is on a device to another device is very important. Why: I think a backup to disk to tape well be the only future of Backups. For Example a Company has to backup 3,6 TB. Then it would be a cool option to backup first to disk. After these Processes are finished a copy Job would alsou put the sam DATA on Tape. That means that the Produktion Server are no longer in use whit backup and if the HDD RAID crashes the data are still on Tape. In the Restore Job then you could easily choose where you took the File Tape or the real Tape. Whit these Feature Bacula will grow to an Enterprise Backup Solution that can be compared whit Veritas. __________________________________ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever |
From: David B. <db...@si...> - 2007-09-11 17:32:42
|
> Item 1: Implement a Copy job type that will copy the > job data from one device to another, for example, > copy from a fiel Tape to a real Tape. This function already exists in Bacula. Define a nextpool resource in the disk pool definition and define a migration job, and schedule it as normal. The migration code offers a number of selection choices; it does not yet have automatic triggers -- that's still outstanding -- but the rest of the function you describe is already there and working.=20 |
From: Kern S. <ke...@si...> - 2007-09-11 18:20:44
|
On Tuesday 11 September 2007 19:30, David Boyes wrote: > > Item 1: Implement a Copy job type that will copy the > > job data from one device to another, for example, > > copy from a fiel Tape to a real Tape. > > This function already exists in Bacula. Define a nextpool resource in > the disk pool definition and define a migration job, and schedule it as > normal. The migration code offers a number of selection choices; it does > not yet have automatic triggers -- that's still outstanding -- but the > rest of the function you describe is already there and working. If I am not mistaken, the problem is that the current code deletes the original job so it is a migrate rather than a copy. Though it may as you indicate be a partial solution, I will implement a Copy job very similar to Migrate that will work more or less identical to the Migrate, except for two things: 1. the original job will not be purged. 2. the new job will be very specially marked a Copy job so that it can be clearly distinguished from the original Backup job. This will allow users to make copies -- the step after that will be to provide some means for the users to be able to indicate they want to use the Copy Volumes during the restore. |