We have a nightly backup on our 6.3 authoring environment. We have a script that shuts down the server, then makes a tar file of the authoring directory, grabbing the crx-quickstart directory, license, initial jar file, and so on. Once it's done, it restarts the server and gzips the backup file.
The tar process is taking a very long time - around 12 hours or more - which impacts when we can use the authoring environment.
I cannot exactly say how big the repository is (the du command never finishes) but the backup files (after gzip) are ~70G. (The last file was 150G, but I'm not sure if it was compressed or not.)
Removing content is not an option, because we don't know what older content they can get rid of or will need later on.
Any recommendations to help us in this process? Or for backups in general?
Solved! Go to Solution.
Views
Replies
Total Likes
Check out
CRX 2.1: Improved backup – Things on a content management system
It is a bit older - but the basic ideas should still be applicable to AEM6.3.
Another idea - use a filesystem that supports snapshots. You would then stop AEM, take a snapshot restart and then back up the snapshot in the background.
Views
Replies
Total Likes
You can run offline compaction to reduce the size of the segment store and that will help in reducing the time it will take for the backup.
You can always do an offline backup. This requires a downtime of AEM, but can be quite efficient in terms of required time compared to an online backup.
You could use Rsync for about 2 times while the system is running and then the last rsync can be taken by shutting down the server where the downtime would be less as the last rsync would only copy delta and most of the data is already copied from previous rsync.
Rsync for the 1st time while the instance is running - takes time for the 1st time
Rsync for the 2nd time while the instance is running - copies over delta should be relatively fast
Rsync for the 3rd time shutting the instance down - quick delta copy and start the instance
After the above stages you could look at options to compress it which shouldn't affect the instance.
Another option to look at is taking SNAPSHOT which is more effective in terms of backup and restore
Check out
CRX 2.1: Improved backup – Things on a content management system
It is a bit older - but the basic ideas should still be applicable to AEM6.3.
Another idea - use a filesystem that supports snapshots. You would then stop AEM, take a snapshot restart and then back up the snapshot in the background.
Views
Replies
Total Likes