nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

To Freeze or Not to Freeze

TJRees

I've seen postings that are related to my question, but none that completely covers what I need....

We are currently backing up our backing store nightly (plus we are also replicating this to another server). Normally, we would freeze the backing store. Lately, there have been nights when we have had to stop the freeze (due to users trying to catch deadlines, and thus the need for TS's availability). However, we continue to run the back-ups.

Question: Will this process corrupt our back-ups/replications? Should we start with a fresh full back-up?

Thanks!

pjacintorees@leggmason.com

Find more posts tagged with

Comments

jerm

Backing up the BS while not in iwfreeze tends to result in incomplete backups because during the backup procedure there tends to be files sharing violations. Maybe try backing up the BS at a time when no one is using TeamSite.

Roses561.ssd.zip

james1

If you have made a backup without the backing store frozen, you must assume that that backup is invalid. When you freeze the backing store, iwserver flushes its in-memory cache to disk, so that everything on disk reflects the most current state of the system. Without that flush, what is on disk may not reflect the most current state of the system. And without the backing store frozen for the duration of the backup, the backed up store may be inconsistent (i.e., you may have backed one section of the backing store, then that section and another section were written to, and then the backup gets to that second section of the backing store, which now expects the first section to be in a different state than what you had backed up).

-- James

--
James H Koh
Interwoven Engineering

Bowker

Even freezing the backup does not 'unlock' all the locked files. There are still a few files that are left open by TeamSite and your backup software may skip those. The only way to ensure no files are open and to get a valid backup is to shut TeamSite down. (At least in the Windows world)

TJRees

Thank you so much for all your responses.

Follow-up question though...We are currently using OD to replicate our backing store and I need some insights regarding OD settings...The first time I deployed the original backing store, I had set this up to preserve ACLs. I then modified the iwidmappings on the destination server since we are using local groups. We continue to run the deployments nightly with "preserve ACLs" just in case new branches or workareas that are shared by local groups are created. I was then expecting to see the source server's local groups still being used for the mappings (sourceServer/localGroup) and that I would need to modify the mappings each time I deactivate/activate the backing store. However, I noticed that the destination server's id mappings are preserved (destServer/localGroup).

Concerns: Any negative side-effects in keeping "preserveACLs" in the deploy script?

pjacintorees@leggmason.com

Migrateduser

What struck me was that freezing your backing store for backup had potential for impacting schedulers. The daily freeze of our backing store to do a backup lasts 1 - 4 seconds. If somebody happened to be making a change during that period and got bounced, I expect they'd just re-read the "cannot write file" msg, try to save again, succeed, and mutter "Computers!".

If your backing store is on a NetApp, you can freeze the backing store, remove the previous snap-shot, snap-shot the backing store volume, unfreeze the backing store, and run your backup on the new snapshot. If not on a NetApp, you can still substitute a copy operation to a filesystem volume in place of making a snap-shot; then backup the filesystem volume. Unless you have an astonishingly fast backup device, this will shorten the duration of the freeze. Maybe to the point you can tell developers "Take a break for supper-breakfast while I do a backup."

HTH