Technical FAQ
The questions people arriving from a desktop ripper actually ask.
▸
Do you execute JavaScript and single-page apps?
Yes, optionally. Tick "render JavaScript" and each page is loaded in headless Google Chrome on our server and captured after the DOM settles, so a React, Vue, Angular or Svelte app yields real HTML instead of an empty root div. It is off by default because it is several times slower — leave it off for classic server-rendered sites. Note that links discovered only through user interaction (click-to-load, infinite scroll) still will not be found; the crawler follows markup, it does not drive the UI.
▸
How do I back up a site that requires a login?
Two fields: cookies and user-agent. Sign in to your own site in a browser, copy the session cookie header, paste it into the cookie field, and the crawler sends it with every request to that host — so members areas, staging sites behind a session gate, and logged-in dashboards mirror correctly. We deliberately do not do credential brute-forcing or login-form automation. If the site runs on a server you control, the Self Backup wizard is the stronger route: it exports the database and files directly over SSH (or via a one-time agent script) instead of replaying a logged-in session. Your cookie string is stored with the job and deleted with it (72 hours, or immediately if you delete the backup).
▸
Do you respect robots.txt?
There is a per-crawl toggle, and it is off by default — because the normal case is you archiving your own site, where robots.txt is a directive to search engines rather than a permission boundary for the owner. Turn it on and we fetch /robots.txt and skip disallowed paths. Either way, robots.txt is not authorization: if the site is not yours, the Acceptable Use Policy says do not crawl it, whatever robots.txt allows.
▸
How hard does the crawler hit a server?
One request at a time per crawl, over a keep-alive connection, with an optional delay of up to 5 seconds between requests. There is no parallel hammering. You also cap depth, page count and total size per job, and you can pause or cancel mid-run from the app.
▸
What does it actually capture?
Links, images, stylesheets, scripts, media sources, iframes, srcset candidates and CSS url() plus stylesheet import references, followed breadth-first from the URL you gave it. Scope is yours to choose: only under this path, this exact host, this host and its subdomains, or anywhere. Off-site assets you pull in are kept in a separate _ext/ folder so the mirror stays browsable. This is a copy of the public front end — for the database and files themselves, use Self Backup (below).
▸
How are the downloaded files organised?
The directory structure mirrors the site. Query-string URLs get a stable hashed suffix so nothing collides, and in the ZIP the HTML and CSS are rewritten to relative local paths — open index.html from your desktop and it browses like the live site, offline. A receipt file records what was captured and when.
▸
Can it back up a site that is already down?
For the mirror: no — we fetch over live HTTP, so the origin has to answer. The Self Backup wizard has the same constraint in a different form: SSH, or the agent script, still needs the server reachable. If the hardware is gone, so are the pages and the data — which is the argument for taking the backup while it is still up.
▸
What is Self Backup, and how is it different from the mirror?
The mirror crawls the public site over HTTP and saves what any browser could see. Self Backup connects to a server you own and exports the database (mysqldump) plus the whole webroot as files, bundled into a single ZIP you download — so you get the actual data, not just the rendered pages. It works even when the app itself is broken, because it never touches the live application. It is the right tool when you need the database and source, not just a copy of the pages.
▸
Do I need SSH for Self Backup?
You have two modes. SSH direct: enter the host, SSH user and a password or private key, and we detect the app + database, dump it and archive the webroot. No SSH? Use the agent script: download a one-time .php file, upload it to the webroot via FTP or the cPanel file manager, open it in a browser — it runs the export on your own server and streams the ZIP back to us over HTTPS, then deletes itself. That works on ordinary shared hosting.
▸
Is it safe to give EZ Website Backup my SSH password or private key?
Credentials are encrypted at rest on our side, travel only over the SSH connection itself, are never written to logs, and are wiped the moment the backup finishes. We only ever send a fixed set of commands (read config, mysqldump, tar) — there is no arbitrary command execution from the UI. The agent script's one-time token expires in about 10 minutes and is single-use, so a stale copy on disk cannot be replayed.
▸
Which apps and databases does Self Backup auto-detect?
It reads Laravel and generic .env files, WordPress wp-config.php, and falls back to a generic webroot scan. You can also pick the type yourself and supply the database host, name, user and password manually. It dumps MySQL/MariaDB via mysqldump; if your database is something else, the webroot files are still archived and you can rebuild the database from your own tools.
▸
What happens if Self Backup cannot find or dump the database?
You still get the files. The wizard falls back to a files-only ZIP and says so plainly — then lets you supply the database details manually and try the dump again. A broken or misconfigured database never blocks you from keeping the webroot.
▸
What are the Self Backup limits?
One self-backup at a time and up to five per day per account during the beta, counted separately from mirror crawls. How long a job takes depends on the size of the database and webroot — you can watch progress live in the wizard. Archives follow the same 72-hour retention as mirrors.
▸
Is the agent script safe to run on my server?
It runs locally on your own server and only performs two things: mysqldump of the detected database and a tar of the webroot, then a single HTTPS upload back to us with its one-time token. It prints what it is doing, and deletes itself — including the temporary files — when it is done. It never reads or exfiltrates anything else.
▸
What cannot be captured?
The mirror cannot capture anything the server does not hand to an anonymous HTTP client: raw database contents, server-side source code, admin panels behind two-factor prompts, streaming media served through DRM, and content that appears only after a user interaction. It is an offline copy of the front end, not a server migration. The Self Backup wizard is the complement: over SSH or the agent script it runs mysqldump and archives the webroot, so the database and files are captured too — provided you own the server and it is still reachable.
▸
Where does the crawl run from, and can I be blocked?
From our servers, so the target sees our datacentre IP, not yours. That protects your home or office connection from getting rate-limited or banned while you archive your own property. It also means an aggressive WAF may challenge us — if a crawl stalls with 403s, add a delay, set a realistic user-agent, and if it is your site, allowlist us.
▸
How long do you keep my mirror and self-backups?
72 hours from the start of the backup, then an hourly scheduled purge deletes the files and the index. Downloaded ZIPs are assembled into a temporary file and removed the moment the transfer completes. Self-backup archives follow the same 72-hour policy, and your credentials are wiped as soon as the job finishes. You can also delete any backup yourself at once. Details are in the Privacy Policy.
▸
Is there an API?
Not yet. The tool is driven from the web app today. If a scripted or scheduled backup is what you need, tell us — it is on the list and demand decides the order.
▸
What does it cost?
Nothing during the beta. If paid tiers arrive, they will be about higher ceilings and longer retention, and we will not silently start charging for an account you already have.