Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: sti on August 04, 2013, 12:42:55 PM
-
Hi SME users,
i'd like to start a discussion on it infrastructure of "SME" companies.
We are a small company with 25 IT-users and allmost 6 TB of productive data.
The fileserver is RAID-5 with 8TB capacity.
Inc and full backups are done as they should, but they take a long time.
My interest is how to solve a total-crash-scenario.
To write back the whole amount of backup-data, besides setting up a new server, just takes to long.
The question is, how to set up a failover-infrastructure with low budget and without loosing performance.
best regards
-
sti
My interest is how to solve a total-crash-scenario.
To write back the whole amount of backup-data, besides setting up a new server, just takes to long.
The question is, how to set up a failover-infrastructure with low budget and without loosing performance.
Probably at the simplest level, Affa using a dedicated on site backup server is the answer.
You can relatively quickly rise the backup server (20 minutes or so) to become the production server in the event of a major server failure.
http://wiki.contribs.org/Affa
Do you read the available documentation ? You should !
affa --rise [--all] JOB [ARCHIVE]
Runs a full restore on the Affa server (!) of all standard files and directories from the backup ARCHIVE of job JOB. In other words: After completion, the Affa box reboots as a clone of the source server. Ensure, that the source server has been powered off before you reboot the Affa box, otherwise the network interface will not come up. This is important, when you run --rise remotely. The --rise feature only works with SME 7 servers und should only be used on dedicated backup servers.
With option --all, all files and directories of the archive as defined by the include[] properties are restored. Files or directories with the same name on the Affa server will be overwritten and cannot be restored by a undorise. This should not be an issue on a dedicated Affa server which does not hold any other data. After a possible undorise those additional restored dada must be removed manually.
Please note, that the rise process backs up the the Affa server itself before doing the restore from the archive. This backup is used by a possible undorise run to restore the Affa server. Only the standard files and directories are backed up. Data in non-standard loctions (like /opt) are untouched and will still exist after the rise run. See also: Backup_server_config#Standard_backup_.26_restore_inclusions
-
AFFA runs on SME8 as well. I have used it (AFFA rise feature)recently in two separate systems and all seems to be OK *
Cheers
Ian
* well, no one has hit me yet, anyway.....
-
Actually, I think there has been some discussion about AFFA on SME8 not handling hardlinks properly. My systems have been so simple I have not noticed any problems - and no-one has reported any to me yet. We shall see.
Cheers
Ian
-
thanks a lot
...AFFA sounds good, Ill give it a try.
the question is now, SME 7 or SME 8 (64bit or 32bit) both with AFFA 2, which is outdated ?
... or setup a pure Centos-Backup-Server with AFFA 3 ?
production-server and backup-server should run the same OS ?
-
...the --rise feature seems to be removed in AFFA 3 ?
unanswered question here..
http://sourceforge.net/p/affa/discussion/1844072/thread/5b9bae31/#89bc
-
I'm using Affa on SME8 and have already replaced the "live" server with the Affa version, which is working fine. It is our intention to switch between the servers every 6 months or so, in order to be sure that the backup is viable.
The regular updates take place over the internet.
-
Hi, I've been working on very similar issues.
Here are my current plans:
1. Run up 1 or more pieces of server hardware (I currently have 3 servers set up for this);
2. Use OpenVZ to run my workloads in virtual containers on those servers;
3. Use Ceph (or similar) to create shared storage between the servers, by combining the local disks on the servers;
4. Run all my services, including SME Server (or similar) in OpenVZ containers, stored on the Ceph shared storage;
5. In addition to our regular tape backup of the fileserver (only 1.5TB), I will PXE boot our 40-odd workstations each night into a linux kernel running Ceph, and combine the the spare disk capacity of all those workstations to make disk-based, short-term (nightly, weekly and monthly incremental) backups of the fileserver.
* OpenVZ gives me the ability to migrate running containers from one piece of hardware to another in case of hardware failure;
(for those installations where there is more than 1 server);
* my current configuration for the fileserver disk array is in an external SCSI RAID chassis. In the event of a hardware failure of the server connected to the SCSI chassis, I have to shutdown hardware, switch cables, restart hardware, and (possibly) migrate a container. This would still take less than 30 minutes all up;
* For an installation with only 1 server, then a server can be rebuilt in less than an hour by simply copying the container image to new hardware.
* If I have multiple servers. I can even migrate containers to do load-balancing (presuming the only storage that service uses is shared storage);
The backup for the large fileserver data needs to be appropriate to the storage size. We currently have a 16-tape LTO library, which we are about to replace/augment with a backup NAS device.
Hope this helps, and I am interested in others' thoughts.
Cheers!
Nik