Completely normal, working as designed. We do this on purpose. Depending on how
you set the migration and reclamation thresholds, that first FILE storage pool
will be internally reclaimed before any migration starts. That reclamation
process will be labeled "Migration". (This has tripped me up
We have always based this on the most recent Last Backup Completion Date/Time
for any filespace owned by a node. I believe this will not become polluted by
replication. That timestamp does get updated by a valid backup, even if no
files in that filespace were actually backed up, because that
I have been asked to move a departmental system into our central Spectrum
Protect backup system. The departmental system is running an open-source backup
product called Bareos, which is a fork of Backula. Anybody done anything like
this?
I assume there is no practical way to simply import the
I set up a cron job that does filespace and node deletions in a batch on
weekends. Then if it takes a long time, I don't care. I set this up back on
server version 5, when deletions took a REALLY long time, and I kept it in V6
to deal with exactly this issue with System State. We've been using
Check your MAXSCRATCH settings for that storage pool. This is a gotcha that has
bitten me in the past.
Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."
From: J. Eric Wonderley
Sent: Thursday,
We have blocked backup of Windows System State for many years, because it could
not be successfully restored. Also backing it up became a major part of nightly
backup load. BMR has never been one of WDSF->Spectrum Protect's strong points.
Roger Deschner
University of Illinois at Chicago
Richard, I'd be looking for a coordinated denial-of-service attack, perhaps
launched from a group of hacked backup client systems. Start looking for
unusual activity in logs on your networking systems such as firewalls.
Roger Deschner
University of Illinois at Chicago
"I have not lost my mind;
I've been using our test setup for further testing, and I'm thinking of
reversing my strategy. I may want to upgrade clients first, and then servers.
The basic issue is still how to overcome the roadblock of having an
Administrator ID automatically switched from TRANSITIONAL to STRICT upon
There is a known and somewhat documented restriction where an administrative ID
which connects to a New (7.1.8 or 8.1.2+) server from a New dsmadmc client,
cannot connect from an Old administrative client anymore, because
SESSIONSECURITY has been switched to STRICT.
I have now discovered that
Test! Test! Test! Search this forum for previous posts about this. There are a
bunch of gotchas. Perhaps one of the most severe is what happens to
administrator IDS. Create some dummy admin IDS to use in testing, because you
can permanently disable your own admin ID if you're not careful. We
10 matches
Mail list logo
