Link to home
Create AccountLog in
Avatar of IT_Group1
IT_Group1Flag for Israel

asked on

Is is safe to enable Circular Logging on Exchange 2010 SP1 ?

Thank you
Avatar of sven_jambor
sven_jambor
Flag of Netherlands image

Depends on what 'safe' is and what you need. If you need up-to-the-last-minute recovery-ability then you shouldn't do it. If you only need to be able to recover up to the last backup (and then a bit) then you can use circular logging.
ASKER CERTIFIED SOLUTION
Avatar of Britt Thompson
Britt Thompson
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
That's for the reason sven_jambor stated. Can't restore.
Avatar of IT_Group1

ASKER

Guys, as you can guess, we're running out of disk space on a fresh installment of Exch 2k10.
I understood what you've said, and understand that circular logging should be only enabled until a full backup is performed.

2 additional questions if i may:
1. the EDBdata size is ~100GB; what's the best practice for a drive size - taking into considerations the logs, daily backup, 60 heavy-duty users, and off course the daily defragment of the DB.

2. Should import from PST's (again, 60 users) should make the server SO sluggish, which takes a toll on mail delivery (20 min delay or more)? The DB is being built as we speak, and it's currently ~40GB, which took 2 days.

Many thx
I'd say you need at least twice the space your databases are going to consume at a very minimum for restore purposes. Disk space is cheap these days so I wouldn't skimp and it makes a BIG difference if you have very fast hard drives. Check Microsoft's best practices here for Exchange Storage. Importing your PSTs will have an impact on server performance, especially if you have slow read/write speeds on your disks.

http://technet.microsoft.com/en-us/library/ee832792.aspx

Importing 40GB over 2-days is incredibly slow...are you doing this from the server or from the clients? What are the specs of your server?
From the clients, and the server spec is:
DL380 G6
2x 5605 CPU's (4 vCPU's dedicated to the exch)
24GB RAM (16GB dedicated to the Exch)
RAID-5 local disks (3x SATA...)
VMware ESX 4 w/ VMXnet3 NIC's (Is there an issue with 2008 R2??)

Thx
There's nothing wrong with R2 and the only thing I can think of from this list is either your disk read/write speeds are very slow or your network is hitting a bottlneck by too much importing at once. I'd recommend importing the PST's server side using the Exchange Management Shell to see if that speeds the process and relieve some stress off the server. You can test the speeds with this:

http://crystalmark.info/?lang=en
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Many Thx guys. The I/o tool looks great.

1. How do I import the PST's server side using the Exchange Management Shell?
2. If you'll find the calc regarding the req's, it'll be great.
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
btw, an alternative to importing the PSTs into Exchange could be to use an archiving solution like Ironmountain Nearpoint or Symantec Enterprise Vault - that way you could put the data into an archive and still keep your operational Exchange database relatively small. Costs money, though, so I don't know if that's an option.
Avatar of Paul Solovyovsky
I woudl recommend an archiving solution as mentioned above because Exchange 2010 un-dedupes all the emails. In previous versions you had single instance, not so with 2010.  I've been installing Enterprise Vault with good results (up to 15K users)
True, but as said, EV or the IronMountain solution aren't exactly cheap. Ex 2010 can do with relatively inexpensive storage and has its own 'archiving' functionality. So the turning point where the gain from gaining single instancing through a third party archiving solution becomes than adding more storage is not easily reached for relatively small deployments. But archiving itself is a great thing if you want to keep your operation db's lean and mean.
oh, btw, just read thru the thread to see f I missed anything. I noticed that your disks are in Raid 5 - that might not be such a good plan. Especially for the drive with the log files you'll want something faster (Raid1, 10 or, if you're really in trouble space-wise, at least RAID 50)