There isn't problem to use the same pool for both backups, due to belong to different clients (different names and client Id's). Both can be start at the same time, too. A simple benefit is the use of only one device for both b-ups (if the device is a LTO4, not a 4mm tape, obviously). Gold rule: if the b-up isn't multiplexed, restore can be faster. About amount of clients supported, it depends on Edition of Networker Server: Workgroup, only 8; Network and Power Edition, unlimited (if you have enough Client Connections licenses), but you have limits on number of simultaneous parallel data streams. Refer to Performance Optimization Guide at Powerlink to tunning Networker. You can compress backup data at client side using directives, or at HW device (tape devices compress data by default)
When Networker runs a backup it assigns a unique identifier called the saveset ID or SSID; this is mapped in the media database to the client from which it came from, time of backup, name of backup, media it is located on etc, so Networker will not get confused over similarly named backups.
You should use common pools to keep similar data together. If you use too many pools you will find tape usage is inefficient as not enough data is backed up a day to fill up a tape (meaning you may be offsiting many part used tapes and using more tapes than you need). If you use too few pools you may also find tape usage is inefficient - for example data with different retentions may occupy the same piece of media and that tape may spend much of its life part used as some of the data will expire long before the rest of the data on the tape expires.
Networker will not give two backups the same timestamp, though they can start at the same time as you see it (ie you can start both backups at 8pm but the timestamp of the backup will have a slight variation from this).
It is difficult to assess the impact on database restores from the information given; you need to avoid writing a huge number of backups to one piece of media simultaneously - saveset data is multiplexed (chopped up into small pieces so it can share the tape with other savesets) so the more backups you are writing simultaneously the more tape has to be read to get your data back. You also need to be aware that if you are not writing data to the tape drive fast enough it will lead to an inefficient use of the tape device so a certain level of multiplexing will be beneficial.
As Claudio states there are several editions of Networker; the workgroup edition is not one that comes up regularly so you almost definitely will have either the network or power edition which allows you to backup unlimited clients. However, that is an unrealistic figure! The maximum number of clients your server will support will depend on things like your server's specification and the frequency and retention of backups - keeping a large number of backups for a long time will result in a large media database which will result in performance issues. As a very generalised figure you will probably be looking at backing up 250-500 clients maximum with one backup server though I have seen instances where a lot more clients were being backed up. Since you are backing up a small number of clients you should not be worrying at the moment.
Performance issues will depend on the amount of data you are backing up and the backup hardware you are using so it is difficult to assess if this will be an issue for you.
The backup can be compressed at the client side by use of directives. The backup is also compressed by default at the tape device. Generally you do not want to do both as double compression can cause the size of the backup to increase on the tape! In general you want to avoid client side compression as this places a heavy processing load on the client - the only time you would consider doing this is if your client is on the end of a very slow network link.
1a) Each backup is identified by ssid name (may or may not be common), ssid/cloneid marker in mdb (unique) and timestamp. With Oracle, based on setting in RMAN script (format) you may or may not have unique backup piece name.
1b) Benefit is to have simple setup where overlapping request make take advantage of same media pool and avoid queueing. Impact, as far as database backups go, is that some larger database backups may take some time to complete and while doing so they lock tape which may contain data from other backups which may be needed for restore while backup is still active. Common approach is to have 1 DB pool and 1 (or more) arch pools. As to how you organize it depends on available hardware/resources. In enterprise environment restores will most probably happenwithin 24h since backup. As such environments are 24/7 busy tape locks might be a problem so I prefer disk device backups of DBs (eg. DD) and tape (VTL) based backups or archive logs (duplicating that at RMAN level toutilize 2 pools within 2 libraries in 2 or more data centers). In your case, which tends to be rather small and simple,you might not need any of those and single pool might be just what you need.
1c) Yes.
1d) Availability and performance. Availability part means that volume required for restore should be available instantly. If using tape (real or emulated one), you may get an issue where restore request may have to wait for volume to become available (if used by other operations or exported out from library). Performance part depends on infrastructure (eg.network) and the way backup was done (heavily multiplexed data on tapes won't perform good during restore).
2) There is no such number. OK, there is according to performance guide by EMC, but I disagree with those numbers stated there. From my experience, scalability of NW is limited by server and it's performance to handle number of savesets. With that in mind, I find the limit to NW server performance to be number of savesets. I have around 80 SQL databases, some 100 Oracle and 40 SAP databases. In total we have 650 NW clients (I say NW clients as probably 50 of those are cluster names at least). We generate 45000 savesets per day and have standard retention of 9 days. While it may sound a bit scary when I say that I need additional backup server at this point, but this is mainly due to the setup and some specifics we use like PowerSnap and dependencies arising from that. The server performance also depends on your hardware too. So there is no uniform formula as there is just too much ingrediants that you have to think about. Nevertheless, the simple the environment the less is required.
3) That's quite small number even the data volume is really what matters. Some hints regarding general performance optimization can be found in EMC's NetWorker Performance Guide so you may start from there.
4) Yes. By default, today all target medias (tape/modern disk solutions) will do that for you. You have option to use client side compression too (within NW), but this is something that is usually not used nowadays as:
i) consumes CPU cycles on client
ii) assuming you use compression on target having compression at source will just make "bad" things
Polska1422
2 Intern
•
128 Posts
0
January 3rd, 2011 12:00
Hi,
There isn't problem to use the same pool for both backups, due to belong to different clients (different names and client Id's). Both can be start at the same time, too. A simple benefit is the use of only one device for both b-ups (if the device is a LTO4, not a 4mm tape, obviously). Gold rule: if the b-up isn't multiplexed, restore can be faster. About amount of clients supported, it depends on Edition of Networker Server: Workgroup, only 8; Network and Power Edition, unlimited (if you have enough Client Connections licenses), but you have limits on number of simultaneous parallel data streams. Refer to Performance Optimization Guide at Powerlink to tunning Networker. You can compress backup data at client side using directives, or at HW device (tape devices compress data by default)
Regards
Claudio
David_Hampson_90e289
2 Intern
•
243 Posts
0
January 4th, 2011 01:00
When Networker runs a backup it assigns a unique identifier called the saveset ID or SSID; this is mapped in the media database to the client from which it came from, time of backup, name of backup, media it is located on etc, so Networker will not get confused over similarly named backups.
You should use common pools to keep similar data together. If you use too many pools you will find tape usage is inefficient as not enough data is backed up a day to fill up a tape (meaning you may be offsiting many part used tapes and using more tapes than you need). If you use too few pools you may also find tape usage is inefficient - for example data with different retentions may occupy the same piece of media and that tape may spend much of its life part used as some of the data will expire long before the rest of the data on the tape expires.
Networker will not give two backups the same timestamp, though they can start at the same time as you see it (ie you can start both backups at 8pm but the timestamp of the backup will have a slight variation from this).
It is difficult to assess the impact on database restores from the information given; you need to avoid writing a huge number of backups to one piece of media simultaneously - saveset data is multiplexed (chopped up into small pieces so it can share the tape with other savesets) so the more backups you are writing simultaneously the more tape has to be read to get your data back. You also need to be aware that if you are not writing data to the tape drive fast enough it will lead to an inefficient use of the tape device so a certain level of multiplexing will be beneficial.
As Claudio states there are several editions of Networker; the workgroup edition is not one that comes up regularly so you almost definitely will have either the network or power edition which allows you to backup unlimited clients. However, that is an unrealistic figure! The maximum number of clients your server will support will depend on things like your server's specification and the frequency and retention of backups - keeping a large number of backups for a long time will result in a large media database which will result in performance issues. As a very generalised figure you will probably be looking at backing up 250-500 clients maximum with one backup server though I have seen instances where a lot more clients were being backed up. Since you are backing up a small number of clients you should not be worrying at the moment.
Performance issues will depend on the amount of data you are backing up and the backup hardware you are using so it is difficult to assess if this will be an issue for you.
The backup can be compressed at the client side by use of directives. The backup is also compressed by default at the tape device. Generally you do not want to do both as double compression can cause the size of the backup to increase on the tape! In general you want to avoid client side compression as this places a heavy processing load on the client - the only time you would consider doing this is if your client is on the end of a very slow network link.
ble1
4 Operator
•
14.4K Posts
1
March 9th, 2011 18:00
My take on questions....
1a) Each backup is identified by ssid name (may or may not be common), ssid/cloneid marker in mdb (unique) and timestamp. With Oracle, based on setting in RMAN script (format) you may or may not have unique backup piece name.
1b) Benefit is to have simple setup where overlapping request make take advantage of same media pool and avoid queueing. Impact, as far as database backups go, is that some larger database backups may take some time to complete and while doing so they lock tape which may contain data from other backups which may be needed for restore while backup is still active. Common approach is to have 1 DB pool and 1 (or more) arch pools. As to how you organize it depends on available hardware/resources. In enterprise environment restores will most probably happenwithin 24h since backup. As such environments are 24/7 busy tape locks might be a problem so I prefer disk device backups of DBs (eg. DD) and tape (VTL) based backups or archive logs (duplicating that at RMAN level toutilize 2 pools within 2 libraries in 2 or more data centers). In your case, which tends to be rather small and simple,you might not need any of those and single pool might be just what you need.
1c) Yes.
1d) Availability and performance. Availability part means that volume required for restore should be available instantly. If using tape (real or emulated one), you may get an issue where restore request may have to wait for volume to become available (if used by other operations or exported out from library). Performance part depends on infrastructure (eg.network) and the way backup was done (heavily multiplexed data on tapes won't perform good during restore).
2) There is no such number. OK, there is according to performance guide by EMC, but I disagree with those numbers stated there. From my experience, scalability of NW is limited by server and it's performance to handle number of savesets. With that in mind, I find the limit to NW server performance to be number of savesets. I have around 80 SQL databases, some 100 Oracle and 40 SAP databases. In total we have 650 NW clients (I say NW clients as probably 50 of those are cluster names at least). We generate 45000 savesets per day and have standard retention of 9 days. While it may sound a bit scary when I say that I need additional backup server at this point, but this is mainly due to the setup and some specifics we use like PowerSnap and dependencies arising from that. The server performance also depends on your hardware too. So there is no uniform formula as there is just too much ingrediants that you have to think about. Nevertheless, the simple the environment the less is required.
3) That's quite small number even the data volume is really what matters. Some hints regarding general performance optimization can be found in EMC's NetWorker Performance Guide so you may start from there.
4) Yes. By default, today all target medias (tape/modern disk solutions) will do that for you. You have option to use client side compression too (within NW), but this is something that is usually not used nowadays as:
i) consumes CPU cycles on client
ii) assuming you use compression on target having compression at source will just make "bad" things