Summary:
-Item 1: Accurate restoration of renamed/deleted files from
+Item 1: Accurate restoration of renamed/deleted files
Item 2: Implement a Bacula GUI/management tool.
Item 3: Implement Base jobs.
-Item 4: Implement from-client and to-client on restore command line.
+Item 4: Implement from-client and to-client on restore command line.
Item 5: Implement creation and maintenance of copy pools
Item 6: Merge multiple backups (Synthetic Backup or Consolidation).
Item 8: Deletion of Disk-Based Bacula Volumes
Below, you will find more information on future projects:
-Item 1: Accurate restoration of renamed/deleted files from
- Incremental/Differential backups
+Item 1: Accurate restoration of renamed/deleted files
Date: 28 November 2005
Origin: Martin Simmons (martin at lispworks dot com)
- Status:
+ Status: Robert Nelson will implement this
What: When restoring a fileset for a specified date (including "most
recent"), Bacula should give you exactly the files and directories
Notes: Legato Networker supports a similar system with full, incr, and 1-9 as
levels.
+Item 1: Implement a server-side compression feature
+ Date: 18 December 2006
+ Origin: Vadim A. Umanski , e-mail umanski@ext.ru
+ Status:
+ What: The ability to compress backup data on server receiving data
+ instead of doing that on client sending data.
+ Why: The need is practical. I've got some machines that can send
+ data to the network 4 or 5 times faster than compressing
+ them (I've measured that). They're using fast enough SCSI/FC
+ disk subsystems but rather slow CPUs (ex. UltraSPARC II).
+ And the backup server has got a quite fast CPUs (ex. Dual P4
+ Xeons) and quite a low load. When you have 20, 50 or 100 GB
+ of raw data - running a job 4 to 5 times faster - that
+ really matters. On the other hand, the data can be
+ compressed 50% or better - so losing twice more space for
+ disk backup is not good at all. And the network is all mine
+ (I have a dedicated management/provisioning network) and I
+ can get as high bandwidth as I need - 100Mbps, 1000Mbps...
+ That's why the server-side compression feature is needed!
+ Notes:
+
+Item 1: Cause daemons to use a specific IP address to source communications
+ Origin: Bill Moran <wmoran@collaborativefusion.com>
+ Date: 18 Dec 2006
+ Status:
+ What: Cause Bacula daemons (dir, fd, sd) to always use the ip address
+ specified in the [DIR|DF|SD]Addr directive as the source IP
+ for initiating communication.
+ Why: On complex networks, as well as extremely secure networks, it's
+ not unusual to have multiple possible routes through the network.
+ Often, each of these routes is secured by different policies
+ (effectively, firewalls allow or deny different traffic depending
+ on the source address)
+ Unfortunately, it can sometimes be difficult or impossible to
+ represent this in a system routing table, as the result is
+ excessive subnetting that quickly exhausts available IP space.
+ The best available workaround is to provide multiple IPs to
+ a single machine that are all on the same subnet. In order
+ for this to work properly, applications must support the ability
+ to bind outgoing connections to a specified address, otherwise
+ the operating system will always choose the first IP that
+ matches the required route.
+ Notes: Many other programs support this. For example, the following
+ can be configured in BIND:
+ query-source address 10.0.0.1;
+ transfer-source 10.0.0.2;
+ Which means queries from this server will always come from
+ 10.0.0.1 and zone transfers will always originate from
+ 10.0.0.2.
Kern notes: I think this would add very little functionality, but a *lot* of
additional overhead to Bacula.
Jmsg(jcr, M_INFO, 0, _("Start Migration JobId %s, Job=%s\n"),
edit_uint64(jcr->JobId, ed1), jcr->Job);
- set_jcr_job_status(jcr, JS_Running);
- set_jcr_job_status(mig_jcr, JS_Running);
- Dmsg2(dbglevel, "JobId=%d JobLevel=%c\n", (int)jcr->jr.JobId, jcr->jr.JobLevel);
-
- /* Update job start record for this migration control job */
- if (!db_update_job_start_record(jcr, jcr->db, &jcr->jr)) {
- Jmsg(jcr, M_FATAL, 0, "%s", db_strerror(jcr->db));
- return false;
- }
-
- Dmsg4(dbglevel, "mig_jcr: Name=%s JobId=%d Type=%c Level=%c\n",
- mig_jcr->jr.Name, (int)mig_jcr->jr.JobId,
- mig_jcr->jr.JobType, mig_jcr->jr.JobLevel);
-
- /* Update job start record for the real migration backup job */
- if (!db_update_job_start_record(mig_jcr, mig_jcr->db, &mig_jcr->jr)) {
- Jmsg(jcr, M_FATAL, 0, "%s", db_strerror(mig_jcr->db));
- return false;
- }
/*
return false;
}
+ /*
+ * We re-update the job start record so that the start
+ * time is set after the run before job. This avoids
+ * that any files created by the run before job will
+ * be saved twice. They will be backed up in the current
+ * job, but not in the next one unless they are changed.
+ * Without this, they will be backed up in this job and
+ * in the next job run because in that case, their date
+ * is after the start of this run.
+ */
+ jcr->start_time = time(NULL);
+ jcr->jr.StartTime = jcr->start_time;
+ jcr->jr.JobTDate = jcr->start_time;
+ set_jcr_job_status(jcr, JS_Running);
+
+ /* Update job start record for this migration control job */
+ if (!db_update_job_start_record(jcr, jcr->db, &jcr->jr)) {
+ Jmsg(jcr, M_FATAL, 0, "%s", db_strerror(jcr->db));
+ return false;
+ }
+
+
+ mig_jcr->start_time = time(NULL);
+ mig_jcr->jr.StartTime = mig_jcr->start_time;
+ mig_jcr->jr.JobTDate = mig_jcr->start_time;
+ set_jcr_job_status(mig_jcr, JS_Running);
+
+ /* Update job start record for the real migration backup job */
+ if (!db_update_job_start_record(mig_jcr, mig_jcr->db, &mig_jcr->jr)) {
+ Jmsg(jcr, M_FATAL, 0, "%s", db_strerror(mig_jcr->db));
+ return false;
+ }
+
+ Dmsg4(dbglevel, "mig_jcr: Name=%s JobId=%d Type=%c Level=%c\n",
+ mig_jcr->jr.Name, (int)mig_jcr->jr.JobId,
+ mig_jcr->jr.JobType, mig_jcr->jr.JobLevel);
+
+
+ /*
+ * Start the job prior to starting the message thread below
+ * to avoid two threads from using the BSOCK structure at
+ * the same time.
+ */
if (!bnet_fsend(sd, "run")) {
return false;
}
jcr->bsr->reposition = true; /* force repositioning */
bsr = find_next_bsr(jcr->bsr, dev);
if (bsr && (bsr->volfile->sfile != 0 || bsr->volblock->sblock != 0)) {
- Jmsg(jcr, M_INFO, 0, _("Forward spacing to file:block %u:%u.\n"),
- bsr->volfile->sfile, bsr->volblock->sblock);
- Dmsg2(dbglvl, "Forward spacing to file:block %u:%u.\n",
+ Jmsg(jcr, M_INFO, 0, _("Forward spacing Volume \"%s\" to file:block %u:%u.\n"),
+ dev->VolHdr.VolumeName,
bsr->volfile->sfile, bsr->volblock->sblock);
dev->reposition(dcr, bsr->volfile->sfile, bsr->volblock->sblock);
}
*/
#undef VERSION
-#define VERSION "1.39.31"
-#define BDATE "16 December 2006"
-#define LSMDATE "16Dec06"
+#define VERSION "1.39.32"
+#define BDATE "20 December 2006"
+#define LSMDATE "20Dec06"
#define PROG_COPYRIGHT "Copyright (C) %d-2006 Free Software Foundation Europe e.V.\n"
#define BYEAR "2006" /* year for copyright messages in progs */
Technical notes on version 1.39
General:
+20Dec06
+kes Add Volume name to Forward spacing message.
+kes Update migration job start time (so it is not zero) to prevent
+ immediate recycling of the job. This *should* fix bug #733.
19Dec06
ebl Fix runscript configuration parsing bug.
17Dec06
projects / bacula / bacula / commitdiff