eaj's questions

I'm kind of a n00b with BE, so forgive me if this should be obvious.

With other backup systems in the past, we have had a general policy of excluding any folder named DoNotBackup. This provides a convenient means of omitting large and/or temporary files.

I was hoping to exclude these folders from my BE backups by setting a global exlusion, thus:

Resource name: \\*\*
Path: **\DoNotBackup
Name: *.*
Apply to subdirectories: yes

However, this appears not to work. At first, I thought we had something wrong with the resource/path syntax, but then I spotted this in the documentation:

You can configure Backup Exec to exclude certain files, or certain types of files, from backups. Exclusions can be added to incremental and differential backup jobs, but not full backup jobs.

Is it really true that I can't tell BE to globally exclude by name in full backups? Of course I could explicitly unselect these folders in the individual jobs, but the idea is to be able to create these folders on an ad hoc basis. Perhaps there's some other mechanism for doing this that's not obvious to someone without a lot of experience? (tbh, I find the BE interface almost—but not quite—as frustrating as Symantec's phone support.)

BE 2012 (Version 14.0)

We have a few Macs in our office which are bound to our Active Directory (Server 2k8R2) domain for login authentication and access to file shares. For the most part this has worked without trouble.

I recently changed my AD password (from the Windows box that is my main desktop machine), and my iMac still wants my old password for logins—even after a reboot. It correctly prompts for the new password when I attempt to connect to Windows smb file shares.

The last time I changed my password, the iMac was running Snow Leopard and picked up the password change as expected.

I'm a little bit of an OS X n00b, so I apologize if this should be obvious. My searching has turned up numerous issues people have had with Lion and Active Directory, but not this particular problem.

Possibly related, we do have mobile accounts enabled for AD in the Directory Utility options. I assume this causes credentials to be cached locally, but it's not clear to me how to get them to update.

EDIT: I tried disabling mobile accounts for AD, but alas, no change. I'm still authenticating with my old password.

This seems like it shouldn't be hard, but I haven't had any luck with either guessing or searching. I'll admit I'm no Windows guru, so forgive me if the answer should be obvious.

I'm trying to get Windows to stop giving me security warnings when I open files or links from a DFS share. I already have a GPO in place which does this for a couple of other network shares:

Policies
  Administrative Templates
    Windows Components
      Internet Explorer
        Internet Control Panel
          Security Page
            Site to Zone Assignment List

Here, I've added host1.mydomain.org and host2.mydomain.org to zone 1 (intranet), and the network shares from these hosts are correctly treated as trusted intranet sites.

However, I now want to add \\mydomain.org\shares to the intranet zone as well. Adding it just like that appears not to work (and on my client machine it appears in the list as file://*.mydomain.org). Other things I've tried include *.mydomain.org and explicitly listing the hosts where the DFS shares originate.

"Turn on automatic detection of the intranet" is also enabled, although I've never been clear on how that actually works.

Servers and DCs are 2008 R2 and clients are (mostly) 7 Pro.

Edit: The next day, it appears that the listing of mydomain.org is in fact having the desired effect. I hadn't logged out and back in during testing; I just did a gpupdate /force and confirmed that the GPO settings appeared in the Internet Options dialog. Is this a bug or just another arcane Windows thing that I don't quite understand?

NOTE: My understanding of this question has changed significantly since I first asked it (see Edit 2 below) but I've left the original version intact.

We've put together an offsite backup system (still testing in-house) that does its data transfer via ZFS send/receive. Machines on both ends are FreeBSD 8.2. Overall, the setup works well.

However, there's clearly something I don't understand about ZFS snapshot stream sizes. I've had a hard time finding information on this, so I'm hoping someone with some more experience can enlighten me.

On the source machine, I have a filesystem of about 47GB for which I need to transfer snapshots:

# zfs list -t snapshot -r -s creation stg/serverx
NAME                   USED  AVAIL  REFER  MOUNTPOINT
(.......)
stg/serverx@20110620  2.88M      -  47.1G  -
stg/serverx@20110621  2.89M      -  47.1G  -
stg/serverx@20110622  2.88M      -  47.1G  -
stg/serverx@20110623  5.44M      -  46.6G  -

I have the snapshot from 6/22 already on the remote server, so I send it the stream generated by

zfs send -i stg/serverx@20110622 stg/serverx@20110623

This is received on the other end with no trouble; however, the stream generated is over 80 gigabytes—nearly twice the size of the entire source filesystem.

Am I misinterpreting the meaning of the "USED" column generated by zfs list? I'd have expected this snapshot stream to be 5.44M plus a certain amount of overhead. It seems I don't quite understand what constitutes overhead.

Possibly useful information: We backup (via rsync) each server to its own filesystem. This particular one seems to generate the largest streams (relative to filesystem and snapshot size). I suspect it may be related to the fact that it's a mail server, so some of its content is pretty dynamic. However, I'd expect this to show up in the snapshot "used" size too.

Obviously, we can save quite a bit by compressing the stream (it can probably be reduced to 12-20% of its original size). Even then, bandwidth will be our limiting factor, so we'd like to understand what makes these streams so large and whether we can do anything to mitigate it.

EDIT: I had forgotten that we have zfs compression enabled on the source filesystem. So the 47-ish gigabytes used does indeed translate to nearly 80 gigabytes of "real" filesystem data. I suppose that's a partial explanation, but I still don't see why the incremental stream from zfs send would be so large.

EDIT 2:

Further investigation of this backup and a couple of others has led to the conclusion that the large transfers were in fact to be expected (due to some upgrades that had taken place). However, I don't see any indication of that large amount of data in the output from zfs list.

I've been through documentation, and I understand that there are a lot of complexities in computing the space used by a snapshot. The zfs man page says the following in the description of the used property:

When snapshots . . . are created, their space is initially shared between the snapshot and the file system, and possibly with previous snapshots. As the file system changes, space that was previously shared becomes unique to the snapshot, and counted in the snapshot's space used.

This makes sense to me. However, I would expect to see a much larger snapshot created at the end of the day the server was upgraded. In fact, it's only a few megabytes. There is no deduplication here (zpool version 15). However, the incremental stream generated by zfs send -i is quite large, and contains all the upgrade information.

Can someone explain this apparent inconsistency? The related question, then, is: How can I get a reasonable estimate of the size of an incremental stream (from, for example, zfs list output)?