How to move magento shop to another server

The following procedure describes the basic needs for moving your magento-shop to another server. There might be additional things to consider (changing domains, DNS, PHP-Configuration, tools & programms on your server) which need to take care of on your own.

1. Backup files in your Magento directory on your old server:

You might empty your var/cache, var/session, var/report and var/log directory first to save space and speed up the backup

2. Create a database dump on your old server:

Use phpMyAdmin, Chive or via console with mysqldump, n98-magerun

3. Set up directory structure for files and create database + user on your new server

4. Move files and database dump to your new server: via FTP, SSH,…

5. Extract file-backup to your new magento directory

6. Check and set file-permissions

Usually 644 for files and 755 for folders.

See also this question for more information: What permissions should I give /var and /media?

7. Import database-dump on your new server:

Use phpMyAdmin, Chive or via console with mysql, n98-magerun

8. Update new database-settings in app/etc/local.xml

9. Update URLs in core_config_data:

You can edit the base_url via Web-Frontend (phpMyAdmin, Chive,…) or use these SQL-statements. You might need to edit the urls for your stores also.

Look for path ="web/unsecure/base_url" and path="web/secure/base_url" in the core_config_data table.

10. Empty var/cache, var/session, var/report, var/log (if you did not do that before you created the backup on the old server)

11. Reindex your data: catalog url rewrites

12. Enjoy your beer!

 

Reference

magento

Tagged :

AWS Storage FAQ

What data is stored in ephemeral storage of an Amazon EC2 instance?

Anything that is not stored on an ebs volume that is mounted to the instance will be lost. For instance, if you mount your ebs volume at /mystuff, then anything not in /mystuff will be lost. If you don’t mount an ebs volume and save stuff on it, then I believe everything will be lost.

You can create an AMI from your current machine state, which will contain everything in your ephemeral storage. Then, when you launch a new instance based on that AMI it will contain everything as it is now.

Meaning of “Warning: Please note that any data on the ephemeral storage of your instance will be lost when it is stopped”

There is a difference between “stop” and “terminate”. If you “stop” an instance that is backed by EBS then the information on the root volume will still be in the same state when you “start” the machine again.

Basically, root volume (your entire virtual system disk) is ephemeral, but only if you choose to create AMI backed by Amazon EC2 instance store.

If you choose to create AMI backed by EBS then your root volume is backed by EBS and everything you have on your root volume will be saved between reboots.

If you are not sure what type of volume you have, look under EC2->Elastic Block Store->Volumes in your AWS console and if your AMI root volume is listed there then you are safe. Also, if you go to EC2->Instances and then look under column “Root Device” of your instance and if it says “ebs”, then you don’t have to worry about data on your root device.

Tagged : / / / /

What is the difference between terminating and stopping an EC2 instance?

terminating-and-stopping-an-ec2-instance

Answer

Terminate Instance

When you terminate an EC2 instance, the instance will be shutdown and the virtual machine that was provisioned for you will be permanently taken away and you will no longer be charged for instance usage. Any data that was stored locally on the instance will be lost. Any attached EBS volumes will be detached and deleted. However, if you attach an EBS Snapshot to an instance at boot time, the default option in the Dashboard is to delete the attached EBS volume upon termination.

Stop Instance

When you stop an EC2 instance, the instance will be shutdown and the virtual machine that was provisioned for you will be permanently taken away and you will no longer be charged for instance usage. The key difference between stopping and terminating an instance is that the attached bootable EBS volume will not be deleted. The data on your EBS volume will remain after stopping while all information on the local (ephemeral) hard drive will be lost as usual. The volume will continue to persist in its availability zone. Standard charges for EBS volumes will apply. Therefore, you should only stop an instance if you plan to start it again within a reasonable timeframe. Otherwise, you might want to terminate an instance instead of stopping it for cost saving purposes.

The ability to stop an instance is only supported on instances that were launched using an EBS-based AMI where the root device data is stored on an attached EBS volume as an EBS boot partition instead of being stored on the local instance itself. As a result, one of the key advantages of starting a stopped instance is that it should theoretically have a faster boot time. When you start a stopped instance the EBS volume is simply attached to the newly provisioned instance. Although, the AWS-id of the new virtual machine will be the same, it will have new IP Addresses, DNS Names, etc. You shouldn’t think of starting a stopped instance as simply restarting the same virtual machine that you just stopped as it will most likely be a completely different virtual machine that will be provisioned to you.

Tagged : / / / / / / /

What’s the difference between ephemeral and volume boot disks?

Different boot sources

There are several different kinds of sources to boot from in the DreamCompute dashboard, but they all need to create some sort of virtual disk for the virtual machine to boot. The virtual disk can use either ephemeral storage or volume block storage. When launching an instance, you have several Boot Source options:

  • Image: Launches an instance from the image you choose onto either an ephemeral disk or a new volume disk.
  • Instance Snapshot: Launches an instance from the instance snapshot you choose onto either an ephemeral disk or a new volume disk.
  • Volume: Launches an instance from an existing bootable volume.
  • Volume Snapshot: Creates a volume from the volume snapshot you choose and then launches an instance using that new bootable volume.

Ephemeral boot disks

Ephemeral disks are virtual disks that are created for the sole purpose of booting a virtual machine and should be thought of as temporary.

Ephemeral disks are useful if you aren’t worried about needing to duplicate an instance or destroy an instance and save the data. You can still mount a volume on an instance that is booted from an ephemeral disk and put any data that needs to be saved on it, instead of using the volume as the root of your OS.

  • Can be snapshotted: Useful for duplicating instances or having a copy of an instance at a certain point in time. Snapshots of ephemeral boot disks are stored as Images and count against DreamCompute’s Image quota.
  • Do not use up volume quota: If you have more instance quota, you can always boot it from an ephemeral disk even if you don’t have any volume quota left.
  • Are destroyed when the instance is terminated: This means you will loose your data if you want to delete an instance to free up some instance quota.

Volume Boot Disks

Volumes are a more permanent form of storage than ephemeral disks and can be used to boot from as well as a mountable block device.

Volume boot disks are useful if you need an easy way to duplicate instances and back them up with snapshots, or if you need a more reliable storage solution for your instance than an ephemeral disk. If you use them, you should plan ahead so that you have enough quota for all of the instances you want to boot.

  • Can be snapshotted: Useful for duplicating instances or having a copy of an instance at a certain point in time.
  • Does not get destroyed when you delete the instance (Unless you select the “Delete Volume on Instance Delete” option): You can delete the instance and your data will still exist as a volume that you can boot from later.
  • Uses your volume quota: This can be pricey if you have lots of instances, or take lots of snapshots.

Source – https://help.dreamhost.com/hc/en-us/articles/217701757-What-s-the-difference-between-ephemeral-and-volume-boot-disks-

Tagged : / / / /

Difference between AWS EFS vs EBS vs S3

1 GB to store in US-East-1: (Updated at 2016.dec.20)

  • Glacier: $0.004/Month (Note: Major price cut in 2016)
  • S3: $0.023/Month
  • S3-IA (announced in 2015.09): $0.0125/Month (+$0.01/gig retrieval charge)
  • EBS: $0.045-0.1/Month (depends on speed – SSD or not) + IOPS costs
  • EFS: $0.3/Month

Further storage options, which may be used for temporary storing data while/before processing it:

  • SNS
  • SQS
  • Kinesis stream
  • DynamoDB, SimpleDB

The costs above are just samples. There can be differences by region, and it can change at any point. Also there are extra costs for data transfer (out to the internet). However they show a ratio between the prices of the services.

There are a lot more differences between these services:

EFS is:

  • Generally Available (out of preview), but may not yet be available in your region
  • Network filesystem (that means it may have bigger latency but it can be shared across several instances; even between regions)
  • It is expensive compared to EBS (~10x more) but it gives extra features.
  • It’s a highly available service.
  • It’s a managed service
  • You can attach the EFS storage to an EC2 Instance
  • Can be accessed by multiple EC2 instances simultaneously
  • Since 2016.dec.20 it’s possible to attach your EFS storage directly to on-premise servers via Direct Connect. ()

EBS is:

  • A block storage (so you need to format it). This means you are able to choose which type of file system you want.
  • As it’s a block storage, you can use Raid 1 (or 0 or 10) with multiple block storages
  • It is really fast
  • It is relatively cheap
  • With the new announcements from Amazon, you can store up to 16TB data per storage on SSD-s.
  • You can snapshot an EBS (while it’s still running) for backup reasons
  • But it only exists in a particular region. Although you can migrate it to another region, you cannot just access it across regions (only if you share it via the EC2; but that means you have a file server)
  • You need an EC2 instance to attach it to
  • New feature (2017.Feb.15): You can now increase volume size, adjust performance, or change the volume type while the volume is in use. You can continue to use your application while the change takes effect.

S3 is:

  • An object store (not a file system).
  • You can store files and “folders” but can’t have locks, permissions etc like you would with a traditional file system
  • This means, by default you can’t just mount S3 and use it as your webserver
  • But it’s perfect for storing your images and videos for your website
  • Great for short term archiving (e.g. a few weeks). It’s good for long term archiving too, but Glacier is more cost efficient.
  • Great for storing logs
  • You can access the data from every region (extra costs may apply)
  • Highly Available, Redundant. Basically data loss is not possible (99.999999999% durability, 99.9 uptime SLA)
  • Much cheaper than EBS.
  • You can serve the content directly to the internet, you can even have a full (static) website working direct from S3, without an EC2 instance

Glacier is:

  • Long term archive storage
  • Extremely cheap to store
  • Potentially very expensive to retrieve
  • Takes up to 4 hours to “read back” your data (so only store items you know you won’t need to retrieve for a long time)

There are several interesting aspects in terms of pricing. For example Glacier, S3, EFS allocates the storage for you based on your usage, while at EBS you need to predefine the allocated storage. Which means, you need to over estimate. ( However it’s easy to add more storage to your EBS volumes, it requires some engineering, which means you always “overpay” your EBS storage, which makes it even more expensive.)

Source

https://stackoverflow.com/questions/29575877/aws-efs-vs-ebs-vs-s3-differences-when-to-use

Tagged : / / /

Connection failed: 404 – Not Found

scmuser created the topic: standalone-pom: Connection failed: 404 – Not Found

Error –

[ERROR] Failed to execute goal org.sonatype.plugins:nexus-m2settings-maven-plugin:1.6.6:download (default-cli) on projec
t standalone-pom: Connection failed: 404 - Not Found -> [Help 1]
[ERROR]

Solution –

Works as expected (only pro 2.7+) allowed.
Tagged :

Nexus – Deployment failed: repository element was not specified in the

scmuser created the topic: Nexus – Deployment failed: repository element was not specified in the

I am facing following error…

Downloaded: repo.maven.apache.org/maven2/org/codehau...exus-utils-1.5.6.jar (245 KB a
t 573.0 KB/sec)
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 9.923 s
[INFO] Finished at: 2015-09-05T16:32:03+05:30
[INFO] Final Memory: 21M/205M
[INFO]
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project my-ma
ven: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -Dal
tDeploymentRepository=id::layout::url parameter -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] cwiki.apache.org/confluence/display/MAVE...joExecutionException
Tagged :

Nexus – Failed to deploy artifacts: Could not transfer artifact

scmuser created the topic: Nexus – Failed to deploy artifacts: Could not transfer artifact

[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 6.457 s
[INFO] Finished at: 2015-09-05T16:44:40+05:30
[INFO] Final Memory: 11M/165M
[INFO]
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project my-maven: Failed to deploy artifacts: Could not transfer artifact com.scmgalaxy.mavensample:my-maven:jar:3.0 from/to deployment ( uvo193bnk02rz2cuv74.vm.cld.sr:8081/nexus...positories/releases/ ): Failed to transfer file: uvo193bnk02rz2cuv74.vm.cld.sr:8081/nexus...3.0/my-maven-3.0.jar . Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] cwiki.apache.org/confluence/display/MAVE...joExecutionException
Tagged :

Difference between Jfrog and Nexus

pasupuleti2 created the topic: difference between Jfrog and Nexus

What are the difference between Jfrog and Nexus?
Which Artifact is good to Jenkins, C#, .Net, C and Java technologies?

-Saritha

rajeshkumar replied the topic: difference between Jfrog and Nexus

I guess you question was difference between Nexus and Artifactory. Jfrog is the company name who developed the software called Artifactory.

Please check it out google to find the diff between Nexus n Artifcatory
www.jfrog.com/blog/artifactory-vs-nexus-integration-matrix/
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

How to generate the pre populated information in metadata.rb in chef?

rajeshkumar created the topic: How to generate the pre populated information in metadata.rb in chef?

How to generate the pre populated information in metadata.rb in chef

You can configure the values in my knife.rb:

cookbookcopyright “Rajesh Kumar”
cookbooklicense “apachev2”
cookbook_email “rajesh@scmgalaxy.com”

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :