ਐਪ ਦੇ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਕਿਵੇਂ ਲਓ (ਅਤੇ ਅਸਲ ਵਿੱਚ ਰੀਸਟੋਰ ਕਿਵੇਂ ਕਰੋ)

ਆਪਣੀ ਐਪ ਦੇ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਲੈਣ ਲਈ, ਇਸਨੂੰ ਕਿਸੇ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰੋ (Postgres ਲਈ ਮਿਆਰੀ ਟੂਲ pg_dump ਹੈ), ਕਾਪੀਆਂ ਡੇਟਾਬੇਸ ਤੋਂ ਵੱਖਰੀ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਇੱਕ ਨੂੰ ਖ਼ਾਲੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੀਸਟੋਰ ਕਰਕੇ ਸਾਬਤ ਕਰੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਖ਼ਤਰਨਾਕ ਬਦਲਾਅ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਇੱਕ ਵਾਧੂ ਬੈਕਅੱਪ ਲਓ। ਤੁਹਾਡਾ ਕੋਡ ਬੈਕਅੱਪ, ਭਾਵੇਂ ਉਹ GitHub ਰਿਪੋਜ਼ਿਟਰੀ ਹੋਵੇ ਜਾਂ ਐਕਸਪੋਰਟ, ਤੁਹਾਡਾ ਡੇਟਾ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦਾ।

ਇਹ ਗਾਈਡ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਹੈ ਜੋ ਇੱਕ ਛੋਟੀ ਐਪ ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਆਪਣਾ ਡੇਟਾ ਗੁਆਉਣ ਦੀ ਚਿੰਤਾ ਖ਼ਤਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨਾਂ ਲਈ ਇਹ Postgres ਵਰਤਦੀ ਹੈ, ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ AI ਨਾਲ ਬਣੀਆਂ ਐਪਾਂ ਇਹੀ ਵਰਤਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਅਸੂਲ ਕਿਸੇ ਵੀ ਡੇਟਾਬੇਸ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਬੈਕਅੱਪ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਇੱਕ ਐਪ ਸਿਰਫ਼ ਆਪਣੇ ਡੇਟਾਬੇਸ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਜਾਣੋ ਕਿ ਹਰ ਬੈਕਅੱਪ ਕੀ ਬਚਾਉਂਦਾ ਹੈ।

ਡੇਟਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਤੁਸੀਂ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦੇ। ਕੋਡ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸੈਟਿੰਗਾਂ ਦੁਬਾਰਾ ਭਰੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ; ਤੁਹਾਡੇ ਗਾਹਕਾਂ ਦੇ ਆਰਡਰ ਨਹੀਂ ਹੋ ਸਕਦੇ।

ਕਦਮ 1: ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿੰਨਾ ਗੁਆ ਸਕਦੇ ਹੋ

ਦੋ ਸਵਾਲ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਯੋਜਨਾ ਤੈਅ ਕਰਦੇ ਹਨ:

• ਤੁਸੀਂ ਹਾਲੀਆ ਕਿੰਨਾ ਡੇਟਾ ਗੁਆ ਸਕਦੇ ਹੋ? ਜੇ ਤੁਸੀਂ ਦਿਨ ਵਿੱਚ ਇੱਕ ਵਾਰ ਬੈਕਅੱਪ ਲੈਂਦੇ ਹੋ ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਡੇਟਾਬੇਸ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਸ ਦਿਨ ਦੇ ਬਦਲਾਅ ਗੁੰਮ ਹੋ ਜਾਣਗੇ। ਇੱਕ ਸ਼ੌਕੀਆ ਐਪ ਲਈ ਇਹ ਠੀਕ ਹੈ। ਆਰਡਰ ਲੈਣ ਵਾਲੀ ਐਪ ਲਈ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋ ਸਕਦਾ।
• ਰੀਸਟੋਰ ਦੌਰਾਨ ਐਪ ਕਿੰਨੀ ਦੇਰ ਬੰਦ ਰਹਿ ਸਕਦੀ ਹੈ? ਇੱਕ ਛੋਟਾ ਡੇਟਾਬੇਸ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਰੀਸਟੋਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਵੱਡਾ ਡੇਟਾਬੇਸ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਛੋਟੀਆਂ ਐਪਾਂ ਲਈ ਇੱਕ ਰੋਜ਼ਾਨਾ ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ ਅਤੇ ਖ਼ਤਰਨਾਕ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹੱਥੀਂ ਬੈਕਅੱਪ ਇੱਕ ਸਮਝਦਾਰ ਸ਼ੁਰੂਆਤ ਹੈ। ਜਿਹੜੀਆਂ ਐਪਾਂ ਵਿੱਚ ਪੈਸਾ ਜਾਂ ਸਿਹਤ ਨਾਲ ਜੁੜਿਆ ਡੇਟਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਵਾਰ ਬੈਕਅੱਪ ਚਾਹੀਦੇ ਹਨ, ਜਾਂ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (ਕਿਸੇ ਵੀ ਪਲ ਤੱਕ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ, ਸਿਰਫ਼ ਆਖ਼ਰੀ ਬੈਕਅੱਪ ਤੱਕ ਨਹੀਂ) ਵਾਲਾ ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਦਮ 2: ਵੇਖੋ ਕਿ ਤੁਹਾਡਾ ਹੋਸਟ ਪਹਿਲਾਂ ਹੀ ਕੀ ਕਰਦਾ ਹੈ

ਬਹੁਤ ਸਾਰੇ ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ ਪ੍ਰਦਾਤਾ ਆਪਣੇ ਆਪ ਬੈਕਅੱਪ ਲੈਂਦੇ ਹਨ। ਪਤਾ ਲਗਾਓ:

• ਕੀ ਤੁਹਾਡੇ ਪਲਾਨ ਲਈ ਬੈਕਅੱਪ ਚਾਲੂ ਹਨ, ਅਤੇ ਇਹ ਕਿੰਨੀ ਵਾਰ ਚੱਲਦੇ ਹਨ?
• ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖੇ ਜਾਂਦੇ ਹਨ?
• ਕੀ ਤੁਸੀਂ ਕਿਸੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ 'ਤੇ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਸਿਰਫ਼ ਰੋਜ਼ਾਨਾ ਸਨੈਪਸ਼ਾਟ 'ਤੇ?
• ਕੀ ਤੁਸੀਂ ਬੈਕਅੱਪ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਦੇ ਸਿਸਟਮ ਅੰਦਰ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ?

ਪ੍ਰਦਾਤਾ ਦੇ ਬੈਕਅੱਪ ਕੰਮ ਦੇ ਹਨ, ਪਰ ਉਹ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨਾਲ ਇੱਕ ਸਾਂਝੀ ਕਮਜ਼ੋਰੀ ਰੱਖਦੇ ਹਨ: ਖਾਤਾ। ਜੇ ਖਾਤਾ ਬੰਦ, ਮੁਅੱਤਲ ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬੈਕਅੱਪ ਵੀ ਨਾਲ ਜਾ ਸਕਦੇ ਹਨ। ਇਸੇ ਲਈ ਤੁਹਾਨੂੰ ਆਪਣੀ ਵੀ ਕਾਪੀ ਚਾਹੀਦੀ ਹੈ।

ਕਦਮ 3: pg_dump ਨਾਲ ਡੰਪ ਬਣਾਓ

pg_dump ਇੱਕ Postgres ਡੇਟਾਬੇਸ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਇਕਸਾਰ ਸਨੈਪਸ਼ਾਟ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਵੀ ਐਪ ਚੱਲਦੀ ਰਹਿ ਸਕਦੀ ਹੈ।

ਇੱਕ ਆਮ ਕਮਾਂਡ, ਜੋ ਤੁਹਾਡੀ ਐਪ ਦੇ ਪਹਿਲਾਂ ਤੋਂ ਵਰਤ ਰਹੇ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ ਨੂੰ ਇੱਕ ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਤੋਂ ਲੈਂਦੀ ਹੈ:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

ਵਿਕਲਪ ਕੀ ਕਰਦੇ ਹਨ:

• --format=custom ਇੱਕ ਕੰਪਰੈੱਸ ਕੀਤੀ ਫਾਈਲ ਲਿਖਦਾ ਹੈ ਜੋ pg_restore ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਇਕੱਲੇ ਟੇਬਲ ਰੀਸਟੋਰ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੜ੍ਹਨਯੋਗ .sql ਫਾਈਲ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ --format=plain ਵਰਤੋ।
• --no-owner ਮਾਲਕੀ ਵਾਲੀਆਂ ਕਮਾਂਡਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਿਸੇ ਹੋਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੀਸਟੋਰ ਕਰਨਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ।
• ਫਾਈਲ ਦੇ ਨਾਮ ਵਿੱਚ ਤਾਰੀਖ਼ ਬੈਕਅੱਪਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦੀ ਹੈ।

pg_dump ਦਾ ਵਰਜ਼ਨ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦੇ Postgres ਵਰਜ਼ਨ ਜਿੰਨਾ ਜਾਂ ਉਸ ਤੋਂ ਨਵਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣਾ pg_dump ਚੱਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ AI ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਕਮਾਂਡ ਲਾਈਨ ਨੂੰ ਹੱਥ ਨਹੀਂ ਲਾਉਣਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਪੁੱਛ ਸਕਦੇ ਹੋ:

custom ਫਾਰਮੈਟ ਵਿੱਚ pg_dump ਵਰਤ ਕੇ ਐਪ ਦੇ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅੱਪ ਬਣਾਓ, ਫਾਈਲ ਦੇ ਨਾਮ ਵਿੱਚ ਅੱਜ ਦੀ ਤਾਰੀਖ਼ ਹੋਵੇ। ਕੋਈ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ ਜਾਂ ਕੋਈ ਸੀਕ੍ਰੇਟ ਨਾ ਛਾਪੋ। ਮੈਨੂੰ ਹੋਣ 'ਤੇ ਫਾਈਲ ਦਾ ਨਾਮ ਅਤੇ ਆਕਾਰ ਦੱਸੋ।

ਕਦਮ 4: ਆਟੋਮੈਟਿਕ ਕਰੋ

ਹੱਥੀਂ ਬੈਕਅੱਪ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਆਪਣੀ ਸੈੱਟਅੱਪ ਦੇ ਹਿਸਾਬ ਨਾਲ ਇਹਨਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਕਰੋ:

• ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਪ੍ਰਦਾਤਾ ਦੇ ਸਮਾਂ-ਸਾਰਣੀ ਵਾਲੇ ਬੈਕਅੱਪ, ਜੇ ਉਹ ਦਿੰਦਾ ਹੈ।
• ਇੱਕ ਸਮਾਂ-ਸਾਰਣੀ ਵਾਲਾ ਜੌਬ ਕਿਸੇ ਸਰਵਰ ਜਾਂ CI ਸੇਵਾ 'ਤੇ ਜੋ pg_dump ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਫਾਈਲ ਸਟੋਰੇਜ ਵਿੱਚ ਅੱਪਲੋਡ ਕਰਦਾ ਹੈ।
• ਇੱਕ ਹੋਸਟ ਕੀਤੀ ਬੈਕਅੱਪ ਸੇਵਾ ਜੋ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਦੀ ਹੈ।

ਜੋ ਵੀ ਚੁਣੋ, ਇਸਨੂੰ ਦੱਸਣ ਦਿਓ ਜਦੋਂ ਬੈਕਅੱਪ ਫੇਲ੍ਹ ਹੋਵੇ। ਇੱਕ ਬੈਕਅੱਪ ਜੌਬ ਜੋ ਤਿੰਨ ਮਹੀਨੇ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਰਿਹਾ, ਇਹ ਇਸ ਦੀ ਸਭ ਤੋਂ ਆਮ ਡਰਾਉਣੀ ਕਹਾਣੀ ਹੈ।

ਕਦਮ 5: ਕਾਪੀਆਂ ਕਿਤੇ ਹੋਰ ਰੱਖੋ

ਨਿਯਮ ਨੂੰ ਅਕਸਰ 3-2-1 ਕਿਹਾ ਜਾਂਦਾ ਹੈ: ਤੁਹਾਡੇ ਡੇਟਾ ਦੀਆਂ ਤਿੰਨ ਕਾਪੀਆਂ, ਦੋ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀ ਸਟੋਰੇਜ 'ਤੇ, ਅਤੇ ਇੱਕ ਕਾਪੀ ਸਾਈਟ ਤੋਂ ਬਾਹਰ। ਇੱਕ ਛੋਟੀ ਐਪ ਲਈ ਇਸਦਾ ਵਿਹਾਰਕ ਰੂਪ ਇਹ ਹੈ:

• ਲਾਈਵ ਡੇਟਾਬੇਸ
• ਪ੍ਰਦਾਤਾ ਦੇ ਆਪਣੇ ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ
• ਤੁਹਾਡੇ ਆਪਣੇ ਡੰਪ ਵੱਖਰੀ ਸਟੋਰੇਜ ਵਿੱਚ, ਜਿਵੇਂ ਕਿਸੇ ਵੱਖਰੇ ਖਾਤੇ ਵਿੱਚ ਇੱਕ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਬਕੇਟ

ਨਾਲ ਹੀ:

• ਪਹੁੰਚ ਸੀਮਤ ਕਰੋ। ਬੈਕਅੱਪ ਵਿੱਚ ਹਰ ਯੂਜ਼ਰ ਦਾ ਡੇਟਾ ਹੁੰਦਾ ਹੈ। ਇਸਨੂੰ ਲਾਈਵ ਡੇਟਾਬੇਸ ਵਾਂਗ ਸਮਝੋ।
• ਰੱਖਣ ਦੀ ਨੀਤੀ ਰੱਖੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਰੋਜ਼ਾਨਾ ਬੈਕਅੱਪ ਦੋ ਹਫ਼ਤੇ ਅਤੇ ਮਹੀਨਾਵਾਰ ਇੱਕ ਸਾਲ। ਪੁਰਾਣੇ ਬੈਕਅੱਪ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਿਟਾਓ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਗੋਪਨੀਯਤਾ ਕਾਨੂੰਨ ਬੇਨਤੀ 'ਤੇ ਨਿੱਜੀ ਡੇਟਾ ਮਿਟਾਉਣ ਦੀ ਮੰਗ ਕਰ ਸਕਦੇ ਹਨ।
• ਬੈਕਅੱਪ ਕਦੇ ਵੀ Git ਵਿੱਚ ਕਮਿਟ ਨਾ ਕਰੋ। ਰਿਪੋਜ਼ਿਟਰੀ ਵਿੱਚ ਪਿਆ ਡੰਪ ਡੇਟਾ ਲੀਕ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

ਕਦਮ 6: ਰੀਸਟੋਰ ਦੀ ਜਾਂਚ ਕਰੋ

ਬੈਕਅੱਪ ਓਨਾ ਹੀ ਚੰਗਾ ਹੈ ਜਿੰਨਾ ਤੁਹਾਡਾ ਆਖ਼ਰੀ ਸਫ਼ਲ ਰੀਸਟੋਰ। ਘੱਟੋ-ਘੱਟ ਹਰ ਕੁਝ ਮਹੀਨਿਆਂ ਬਾਅਦ, ਅਤੇ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਬਾਅਦ:

1. ਇੱਕ ਨਵਾਂ, ਖ਼ਾਲੀ ਡੇਟਾਬੇਸ ਬਣਾਓ। ਜਾਂਚ ਲਈ ਲਾਈਵ ਡੇਟਾਬੇਸ ਉੱਤੇ ਕਦੇ ਰੀਸਟੋਰ ਨਾ ਕਰੋ।
2. ਸਭ ਤੋਂ ਨਵਾਂ ਬੈਕਅੱਪ ਉਸ ਵਿੱਚ ਰੀਸਟੋਰ ਕਰੋ:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

ਸਾਦੀ .sql ਫਾਈਲ ਲਈ, ਇਸਦੀ ਬਜਾਏ psql "$TEST_DATABASE_URL" -f backup.sql ਵਰਤੋ।

1. ਜਾਂਚੋ ਕਿ ਹਰ ਟੇਬਲ ਮੌਜੂਦ ਹੈ, ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਲਾਈਵ ਡੇਟਾਬੇਸ ਨਾਲ ਮਿਲਾਓ, ਅਤੇ ਕੁਝ ਤਾਜ਼ਾ ਰਿਕਾਰਡ ਵੇਖੋ।
2. ਜੇ ਹੋ ਸਕੇ ਤਾਂ ਐਪ ਦੀ ਇੱਕ ਕਾਪੀ ਇਸ ਨਾਲ ਜੋੜੋ ਅਤੇ ਲੌਗਇਨ ਕਰਕੇ ਵੇਖੋ।
3. ਲਿਖ ਲਓ ਕਿ ਰੀਸਟੋਰ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਾ। ਇਹ ਤੁਹਾਡਾ ਅਸਲ ਰਿਕਵਰੀ ਸਮਾਂ ਹੈ।

ਕਦਮ 7: ਖ਼ਤਰਨਾਕ ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਬੈਕਅੱਪ ਲਓ

ਇਹਨਾਂ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਤਾਜ਼ਾ ਬੈਕਅੱਪ ਲਓ:

• ਕੋਈ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣਾ ਜੋ ਕਾਲਮ ਡਿਲੀਟ ਜਾਂ ਰੀਨੇਮ ਕਰਦਾ ਹੈ
• ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਇੰਪੋਰਟ ਕਰਨਾ
• AI ਏਜੰਟ ਨੂੰ ਡੇਟਾ ਮਾਡਲ ਵਿੱਚ ਵੱਡੇ ਬਦਲਾਅ ਕਰਨ ਦੇਣਾ
• ਪੁਰਾਣੇ ਰਿਕਾਰਡ ਮਿਟਾਉਣਾ

AI ਨਾਲ ਬਣੀ ਐਪ ਵਿੱਚ, ਏਜੰਟ ਇੱਕ ਫੀਚਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਟੇਬਲ ਦਾ ਢਾਂਚਾ ਬਦਲ ਸਕਦਾ ਹੈ। ਚੈੱਕਪੌਇੰਟ ਅਤੇ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਤੁਹਾਡਾ ਕੋਡ ਵਾਪਸ ਲਿਆਉਂਦੇ ਹਨ, ਪਰ ਮਿਟਾਈਆਂ ਕਤਾਰਾਂ ਵਾਪਸ ਨਹੀਂ ਲਿਆਉਂਦੇ। ਇੱਕ ਵੱਡੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਤੀਹ ਸਕਿੰਟ ਦਾ ਬੈਕਅੱਪ ਸਸਤਾ ਬੀਮਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ

• ਇਹ ਮੰਨਣਾ ਕਿ Git ਜਾਂ ਕੋਡ ਐਕਸਪੋਰਟ ਬੈਕਅੱਪ ਹੈ। ਇਸ ਵਿੱਚ ਕੋਡ ਹੈ, ਡੇਟਾ ਨਹੀਂ।
• ਰੀਸਟੋਰ ਕਦੇ ਟੈਸਟ ਨਾ ਕਰਨਾ। ਬਹੁਤ ਸਾਰੇ ਬੈਕਅੱਪ ਉਦੋਂ ਹੀ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਖ਼ਾਲੀ, ਅਧੂਰੇ ਜਾਂ ਨਾ ਪੜ੍ਹੇ ਜਾਣ ਵਾਲੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।
• ਬੈਕਅੱਪ ਉਸੇ ਖਾਤੇ ਵਿੱਚ ਰੱਖਣਾ ਜਿੱਥੇ ਡੇਟਾਬੇਸ ਹੈ। ਇੱਕ ਹੈਕ ਹੋਇਆ ਜਾਂ ਬੰਦ ਹੋਇਆ ਖਾਤਾ ਦੋਵੇਂ ਗੁਆ ਦਿੰਦਾ ਹੈ।
• ਅਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਭੁੱਲਣਾ। ਡੇਟਾਬੇਸ ਫਾਈਲ ਦਾ ਰਸਤਾ ਰੱਖਦਾ ਹੈ; ਤਸਵੀਰ ਆਪ ਸਟੋਰੇਜ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।
• ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਸੀਕ੍ਰੇਟ ਛੱਡਣਾ। ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ ਸਕ੍ਰਿਪਟ ਦੇ ਟੈਕਸਟ ਤੋਂ ਨਹੀਂ, ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਤੋਂ ਪੜ੍ਹੋ। ਵੇਖੋ API ਕੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ।

ਬੈਕਅੱਪ ਅਤੇ Mythex

Mythex ਪ੍ਰੋਜੈਕਟਾਂ ਕੋਲ ਇੱਕ ਸਮਰਪਿਤ Postgres ਡੇਟਾਬੇਸ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਕਨੈਕਸ਼ਨ ਵੇਰਵੇ ਵਰਕਸਪੇਸ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਵਿੱਚ ਪਾਏ ਜਾਂਦੇ ਹਨ। Mythex ਦੇ ਡੌਕਸ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਜਾਂ ਰੀਸਟੋਰ ਫੀਚਰ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਆਪਣਾ ਬੈਕਅੱਪ ਆਪ ਯੋਜਨਾਬੱਧ ਕਰੋ: ਏਜੰਟ ਨੂੰ ਡੰਪ ਬਣਾਉਣ ਲਈ ਕਹੋ, ਇਸਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖੋ, ਖ਼ਾਸ ਕਰਕੇ ਵੱਡੇ ਬਦਲਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ। ਪ੍ਰੋਜੈਕਟ ਐਕਸਪੋਰਟ (Pro) ਵਿੱਚ ਤੁਹਾਡਾ ਕੋਡ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਸੀਕ੍ਰੇਟ ਅਤੇ node_modules ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ; ਇਸ ਵਿੱਚ ਡੇਟਾਬੇਸ ਦੀਆਂ ਕਤਾਰਾਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਡੌਕਸ ਵਿੱਚ Database ਅਤੇ Data ownership ਵੇਖੋ। ਡੇਟਾਬੇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਨ ਲਈ, Postgres ਕੀ ਹੈ ਪੜ੍ਹੋ।

ਬੈਕਅੱਪ ਚੈੱਕਲਿਸਟ

• ਤੈਅ ਕੀਤਾ ਕਿ ਤੁਸੀਂ ਕਿੰਨਾ ਡੇਟਾ ਗੁਆ ਸਕਦੇ ਹੋ ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਬੰਦ ਰਹਿ ਸਕਦੇ ਹੋ
• ਜਾਂਚਿਆ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਹੋਸਟ ਕਿਹੜੇ ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ ਦਿੰਦਾ ਹੈ
• ਤੁਹਾਡਾ ਆਪਣਾ ਡੰਪ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਤੁਹਾਨੂੰ ਸੂਚਨਾ ਮਿਲਦੀ ਹੈ
• ਕਾਪੀਆਂ ਡੇਟਾਬੇਸ ਤੋਂ ਵੱਖਰੀ ਜਗ੍ਹਾ 'ਤੇ, ਸੀਮਤ ਪਹੁੰਚ ਨਾਲ ਰੱਖੀਆਂ ਹਨ
• ਰੱਖਣ ਦੀ ਨੀਤੀ ਲਿਖ ਕੇ ਰੱਖੀ ਹੈ
• ਅਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਦਾ ਵੀ ਬੈਕਅੱਪ ਹੈ
• ਖ਼ਾਲੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੀਸਟੋਰ ਟੈਸਟ ਕੀਤਾ, ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ ਜਾਂਚੀ
• ਹਰ ਖ਼ਤਰਨਾਕ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਬੈਕਅੱਪ ਲਿਆ ਜਾਂਦਾ ਹੈ

ਸਵਾਲ