VM Backup & Restore in Virtualbox

Hi!
I’ve installed erpnext vm on my win10 virtualbox and seems like a good product. Before committing company data though, I’d like a concise guideline for backup and restore of said vm.

From what I’ve gathered in this forum; “stuff breaks” following bench update. I’d like to know how I’d immediately revert to functional instance of vm without hassle.

I’m familiar with virtualbox and know how to clone closed VMs… but everytime I “sudo shutdown now”… system hangs and never closes… so I have to force shutdown… which also seems to “break stuff”…so I think… Hmmm… take a snapshot while system is running… but this is for ‘system state’.

I’m not running a web facing server, but would under hosted / paid conditions… that is if I can even start testing this product. For now the setup I envision is strictly local. So I’ll boil it down to 4 questions.

  1. Why can’t I properly shut down ubuntu 14.04 (vm) from sudo shutdown now command?
  2. Is there a clear & concise path to immediately revert to a functional instance of VM (from Virtualbox back to Virtualbox) following bench update failure… by this I mean a step method.
  3. Is it necessary to perform bench update if my system is running fine?
  4. Am I just deferring grief if I avoid bench updates?

Thanks in advance for the “link”-half-phrase"answers" but I’d appreciate it if responder(s) could take the substantial time required to copy paste RELAVENT answers.

I do appreciate the considerable efforts to create and maintain ERPNext and I’d love to use it regularly but my business parameters are such that we need a strict implementation and execution methodology for tech that we adopt / deploy.

Kind regards

@Django: I am not able to comment on Question 1 in your list (shutting down ubuntu ) instrumentally. I defer it to Frappe team to comment. A side note, However, is you can always utilize Virtual Box’s ACPI Shutdown capability to turn it off properly regardless.

Regarding your other questions, here are some points based on our experience

Is there a clear & concise path to immediately revert to a functional instance of VM (from Virtualbox back to Virtualbox) following bench update failure… by this I mean a step method.

While you play with ERP Next on a Virtual Box VM (which is hardly going to be your long-run production infrastructure, anyway), you may have it as a habit to export your VM to an image file prior to doing every next bench update run. In such way, you will be able to quickly restore your VM from such an image ‘backup’ if anything goes wrong. http://askubuntu.com/questions/588426/how-to-export-and-import-virtualbox-vm-images is a good starting point to start your research.

Is it necessary to perform bench update if my system is running fine?

The way ERP Next is currently being developed and tuned suggests you to upgrade often (I know this is a bit risky from the stand point of common sense and generic release management practices). however, the cost of delayed upgrade with ERP Next could be even higher then the cost of accepting the fast update risks.
When you go into production, you may want to have a separate staging server where you do the smoke test of every update before applying it to the production facility.
Also, try to run and watch the functional test suite on your instance of ERP Next or at least watch the latest build status with functional tests of ERP Next on Trevis to get an idea on the health of the most recent trunk build of Frappe and ERP Next…

Am I just deferring grief if I avoid bench updates?

to tell the long story short, yes.

1 Like

Hi Gvyshnya,
Thank you for your considered and prompt response. Your clear advice is excellent and I intend to continue testing ERPNext with your backup / restore guidelines.

Having said that, and Not For Nothing; the description of the ERPNext PRODUCTION Image VM on ERPNext website says: “Stable build, for Production use” ?? (until bench update that is)

Perhaps this description is misleading?.. I suppose I’m questioning why would ERPNext bother bundling it’s excellent program (with known parameters) into a ubiquitous server (ubuntu 14.04; also with known parameters… even known settings) for a ubiquitous virtualisation program like Virtualbox (also with know parameters & settings) only to yield a process that results in definite failure with updates? This issue absolutely defeats me. I’m baffled because ERPNext touts this as a closed system that ‘just works’, yet bench updates (not maybe) break it ???

… I mean… ERPNEXT PRODUCED The Image!!..Wouldn’t they check that it ‘JUST WORKS’ on VBOX & VMWARE BEFORE updating bench daily no less?

Can you tell me if I’m missing something? Perhaps because I don’t ‘think like a developer’ ? I’d completely understand if they broke across the spectrum of different possible deployments, OSs, virtuallisation programs, etc… but this is not the case for the .ova path which is necessarily very specific.
Apparently this path (math) is as follows:

ERPNext.ova file (produced by ERPNext)
+
import into Virtualbox (or VMWare)
+
Ubuntu 14.04

deployment is broken following bench update
+
user deal with it

Sincere Apologies for being direct but I’m sure I’m not the only one who’s spotted this logic bug.

Kind regards,

@Django: let me help to clarify a few things on Production vs. Development VM images

  • ERP Next can run with Developer mode switched on or off - Development VM image leverages Developer mode switched on by default, as opposed to Production VM image
  • bench update command is intended to use for updating ERP Next - it is available regardless the Dev mode switched off or not (however, you are right that the quality of a particular update coming through Bench Update may be different - sometimes it is less then production quality indeed)
  • in my experience, bench update rarely crashed the system severely - however, some of the system modules could degrade temporarily if a new release of ERP Next trunk is released with critical bugs missed (this happens from time to time, indeed);
  • if you keep saying about bench update breaking your system, you may want to raise special topics on the forum to discuss it as suspicious bugs

The reason why I mentioned that even production VM image is hardly going to be your choice for production mode is that it is a little restricted, anyway. It is good for small companies that do not have qualified in-house IT admins/developers. However, if an organization has its own IT talent, it is always better to deploy it manually on a server that you fully control.

On a separate note, the overall quality of ERP Next builds is one of the key focus areas of the community right now. You may want to review Beta Testing Process to see the active discussion on Beta Testing process and all of the collateral issues related to quality and production risks.

Hi @Django ,

I helped make the OVA builds that you are using. I will have to apologize for what the text on the Download page implies. You would primarily want to use the VM Build for evaluation purposes. The VM Build can be used to Production, however as @gvyshnya has mentioned, it’s far more sensible to host it on your own server / VPS with your configuration.

bench update in most cases will not break your setup, there are always unforeseen circumstances where a migrate breaks. However, in that case the Frappe Team is really quick in deploying a fix, so if you want to be wary of any issues, just wait it out after any Major Release. The way the team deploys right now, they only push hotfixes on a regular basis, so updating everyday is not a problem.

VM Builds are built daily from scratch, the whole process is automated. Moving the OVA Build to Ubuntu 16.04 was in the pipeline, however I have since left the company, and I’m not sure where the priority is on that.

1 Like

To answer the question ;- Why can’t I properly shut down ubuntu 14.04 (vm) from sudo shutdown now command?

I have found that Ubuntu server (without a GUI) is not shipped with acpi support therefore within a virtualisation platform, ie VirtualBox, KVM or Proxmox , the shutdown command is ineffective.

If you just install acpi support with apt-get you should get the functionality tonshutdown the guest as normal.

1 Like

Thank you gyyshnya and vjFalk for your detailed answers; it’s greatly appreciated.

I’ve since abandoned the VM build (i find it cumbersome) in favor of just straight ‘easy install’ (on a ubuntu 16.04 local server in Virtualbox on my PC) per instructions on ERPNext website and it worked fine. For anyone attempting such an (easy-install) install… i can suggest to not install openssh during server setup and running install remotely with ssh… somehow this is problematic and causes stuff to break… i vaguely recall a ‘pip’ or ‘pipe’ error repeating itself. In fact: only default system utilities should be installed on ubuntu server setup… that’s my experience anyway.

I suppose it’s worthwhile to explain my objectives with ERPNext; I’d like to familiarize myself with it and when I feel comfortable enough, obtain paid hosting from erpnext which would include my website facing the internet. So I’d like assurances that it would be feasible to port my instance of ERPNext to your servers eventually… and what would be ‘best practice’ to do this at the onset.

At any rate, at this point I’d like to ‘lock-down’ methods for backup and bench update; please advise ‘best practice’ for a productions setup?.. Off the top of my head, I’d clone my server, run bench update on that clone and if all seems to work on clone, then do bench update on server. Cloning is easy & quick on virtualbox. What is ideal frequency of bench update for production setup? vjFaLK mentioned waiting only for ‘Major Releases’… not sure how i’d go about this. I’m hoping for an ‘easy’ and ‘safe’ method to proceed for both backup and bench update.

Note that I’ll be ‘double-entering’ data into ERPNext and my tried/tested current accounting system; so i’ll be grateful if the backup and update methods are explicit and repeatable. The sooner I’m comfortable with ERPNext, the sooner I’ll abandon old accounting system and commit more resources to ERPNext.

I’ll research this while awaiting your answers.

Kind regards,
Django

Hmmm … following some research, … is it simply enough to copy the zipped file in the folder …sites/{sitename}/private/backups … to an off-server location? Is a restore of this sql data sufficient to be ‘up and running’ as before (with a little help from community of course) ?

This would re-assure me prior to bench updates anyway…please let me know if i’m on the right path.

If this is, in fact, sufficient to restore database (following recommended procedures) …I think I saw that some people automate backup of this zipped file to dropbox… but I’d rather store it ‘in-house’ for now.

I’d appreciate any advice. Thanks

… Also, could’nt I backup / restore this database from phpmyadmin? (after installing it of course)… it seems to me that would be ideal if possible…? I know that this can be problematic sometimes.

Anyway I’m in pursuit of best practice for backup/restore/update so please offer the most commonly used and supported solutions regardless of how easy they may or may not be.

@Django: let me share a few comments to the backup-related questions/points in your recent posts

  1. The standard method of doing backup and backup restore in ERP Next is summarized in the discussion thread per Backup & Restore (respective bench commands explained in the reference in more details). That’s who developers in Frappe assumed it to use by the end users
  2. There are options to integrate your backup facility with Dropbox - see https://frappe.github.io/erpnext/user/manual/en/setting-up/third-party-backups and https://github.com/frappe/erpnext/wiki/Setting-up-Backup-Manager for more info
  3. phpmyadmin can surely work as a tool for the database backup - however, you have to take into account that every backup point should aggregate both the database backup and the backup of your site and custom application files (that’s why the method per the item 1 above designed)
  4. It is a good practice to also replicate your backup files to an off-server location just for redundancy and fault-tolerance reasons

As for your question on hosting with Frappe-managed ERP Next cloud, it should be determined by your choices. Your choices will in turn be dictated by the extent of customization/functional extensions you would like to apply on top of the standard capabilities of ERP Next. Everything that would require serious extensions (especially with back-end programming, new DocType introduction etc.) will not be facilitated in Frappe-backed cloud environment. You will have to set up your own server for the purpose then. Such a server can be obviously a cloud-based one :slight_smile: - AWS, Digital Ocean and plenty of other options exist in the marketplace to go.

Hi George,

Thanks very much for your help and now this email. I’m most obliged… is there a reason you didn’t post this on forum?

I will follow your link for backup and restore as I understand it references a method that is more comprehensive through bench than any other solution.
The last question I have is: how often should I bench update? Of course I would do a backup prior.

I’ve researched the recommended frequency for bench update on forums but could not find anything.
Once a week seems reasonable to me but I’d rather follow any guidelines that might exist… as you’ve already suggested.

Kind regards,

Stavros

@Django (Stavros): thank you for your kind words and message.

In terms of frequency of bench update, once a week may work for your purpose.

Development servers may benefit from daily updates though.

P.S. This all goes to the forum :slight_smile: - email is sent by the forum engine automatically to duplicate communications in case you have not visited the forum for more then a day

If you wanted to do real time redundant setups how would you go about it? We have erpnext setup on DigitalOcean and are looking to do a real time backup as part of our redundancy plan. Thoughts? Tools?