RE: [BackupPC-users] Managing Outlook pst files

[Ryan J. <ry...@un...>]

Thanks for this infomration.

It seems that my setup (using primarially rsync on cygwin) confirms that
there is a problem with this linking feature. Looking at my old backups =
and
logs, it seems that the "bad" pst files are not removed, and are not =
linked.
The log files do not indicate that anything special happened to them =
upon
the backup either... For example:

create   644   400/401    76824576 MAIN.pst
Remote[1]: read errors mapping "ation Data\Microsoft\Outlook/MAIN.pst" =
(in
outlook_data): (13) Permission denied
  create   644   400/401     6766592 =
Personalpop3.myrealbox.com-00000010.pst
  create   644   400/401     7569408 Unganamail.kabissa.org-00000058.pst
Remote[1]: read errors mapping "ation
Data\Microsoft\Outlook/Unganamail.kabissa.org-00000058.pst" (in
outlook_data): (13) Permission denied
  create   644   400/401     2302976 Unganamail.kabissa.org-00000059.pst
Remote[1]: read errors mapping "ation
Data\Microsoft\Outlook/Unganamail.kabissa.org-00000059.pst" (in
outlook_data): (13) Permission denied

I don't imagine that this is a very high-priority issue - for now I will =
try
to get users to manually copy pst files to a network drive when they =
revieve
an e-mail notification instead of loggin on to the cgi interface.=20

We have a few other offices interested in Backuppc, and they all run an
enviornment where everyone keeps outlook open as long as their computer =
is
turned on. This is why I wanted to enquire about this functionality. In
these locations, it seems that manual pst backups will be a must, and =
the
cgi interface is certainly the most "professional" way to do it. Perhaps =
I
should keep monitoring things from future versions?

Cheers,
Ryan
=20


> -----Original Message-----
> From: Craig Barratt [mailto:cba...@us...]=20
> Sent: 28 February 2005 01:36 AM
> To: Ryan Jacobs
> Cc: bac...@li...
> Subject: Re: [BackupPC-users] Managing Outlook pst files=20
>=20
>=20
> "Ryan Jacobs" writes:
>=20
> > Hello. I have a question related to how backuppc manages=20
> locked .pst=20
> > files. I have been up and down the list archives, and have=20
> even posted=20
> > a similar question to this list (w/o reply), and I still=20
> can't seem to=20
> > get clarity on a couple things. Sorry to bring up a similar=20
> question=20
> > to the list again, but I'm not sure where else to go.
> > =20
> > Basically, I am wanting to understand how backuppc manages=20
> locked pst=20
> > files in the 'long-term.' I understand that locked files=20
> are simply a=20
> > problem that backuppc cannot overcome, and I understand how the=20
> > outlook e-mail warning feature works (and it's quite a nice=20
> add-in).=20
> > What I don't know is how does backuppc manage the 'bad' pst=20
> files that=20
> > it comes across, or the good pst files that are manually=20
> captured. For=20
> > example, if a user receives an e-mail warning that their=20
> outlook files=20
> > have not been backed up in xx days, and they manually run an=20
> > incremental backup, then this backup only lasts a few days (until=20
> > incremental backups expire). If they manually run a full backup=20
> > instead, then this good .pst backup may get some extra mileage, but=20
> > there is not guarantee that it makes it past the first full backup=20
> > expiry period... and thus it does not propagate through=20
> time. This all=20
> > means that if a user skips one of the e-mail warnings, and=20
> then needs=20
> > to recover mail data, it is unlikely that they will find ANY useful=20
> > old mail backups... even though there are plenty of backups=20
> for their=20
> > pc dating back many weeks, and even though they DID=20
> remember to do a manual backup a couple e-mail warnings ago.
> > =20
> > I also saw somewhere that backuppc attempts to 'link' bad=20
> .pst files=20
> > with previous good copies in the pool. However, I cannot find any=20
> > indication that this is happening with my setup (Debian package=20
> > version:  2.1.0pl1)
> > =20
> > So I am simply wondering how one can assure that the "good"=20
> > captures/backups of problematic .pst files propagate through the=20
> > backup storage so there is always (at least) an old .pst=20
> backup which=20
> > is useful.
>=20
> If a pst file is bad (noted by parsing the output of=20
> smbclient or rsync) it is removed.  Older backups are scanned=20
> (using the same relative path) and if any file of the same=20
> name is found it is assumed good and a hardlink is created=20
> pointing to that same file.
>=20
> So that way the older good pst file is effectively "copied"
> (hardlinked) into the most recent backup.  It will survive=20
> expiry of the older backup.  This way the most recent good=20
> pst file should always be propagated forward.
>=20
> That said, this feature is a little fragile since it depends=20
> upon the formatting (and correct parsing) of the output from=20
> smbclient or rsync.  Since rsync on cygwin/WinXX seems to=20
> print additional prefixes (eg: cygdrive/...) to the file=20
> paths in its output messages, I suspect this pst feature=20
> might be broken with rsync.
>=20
> Craig
>=20